• Contrast Security
  • Book a Demo

What is a Cross Site Scripting (XSS)?

In Java



Cross Site Scripting (XSS) occurs when an application takes untrusted data from an HTTP request (URL, URL parameters, form fields, headers, cookies, body) and writes it to a web page without properly escaping special characters, in order to be interpreted as text instead of commands for the HTML context (body, attribute, script, style, etc...).


The flow that untrusted data follows from an untrusted source to the HTTP response can often be quite complex with application frameworks, business logic, data layers, libraries, and other complicated code paths that make XSS difficult to see.


There are three types:

Reflected XSS

Reflected XSS occurs when a malicious script is sent to a user (typically in a URL), the user's browser forwards that attack to the vulnerable application, and the application sends the attack to the victim's browser where it executes.

Stored XSS

Also known as "Persistent XSS", this variant is often more dangerous than other types. Stored XSS occurs when an attacker sends a malicious script to a vulnerable application, which stores that data (perhaps in a database). Later, the attack is sent back to the victim's browser in the course of regular browsing, where it executes.

DOM-based XSS

DOM-based XSS occurs entirely in a user's browser and does not involve the server-side application. A DOM-based XSS attack is possible if the web application takes untrusted information, such as information from a URL, and writes it to the Document Object Model (DOM), where it executes.



XSS attacks are extremely common. There are many automated tools that crawl websites and send XSS attacks to see if they end up in HTML.



Cross-site scripting vulnerabilities typically allow an attacker to masquerade as the victim in order to carry out any actions that the user is able to perform and access any of the user's data; capture the user’s login credentials; perform virtual defacement of websites, changing its messaging, look and feel; inject trojan functionality into websites, and creating a backdoor that gives malicious users access to the user’s system.

XSS vulnerabilities are especially dangerous because an attacker exploiting an HTML or JavaScript vulnerability can gain the ability to do whatever the user can do, and to see whatever the user can see – including passwords, payments, sensitive financial information, and more. 

XSS is particularly dangerous because victims, both the user and the vulnerable application, often won’t be aware they've been exploited.


Serious impact: Attacker gains access to an application holding sensitive data, such as banking transactions, emails, or healthcare records.


Critical impact: If the compromised user has elevated privileges within the application, the attacker can take full control of the vulnerable application and compromise all users and their data.


XXS in Java

If the input or output of the parameter can be removed, it should. Otherwise, encode the parameter using the appropriate technique, based on where the parameter is rendered on the page:



Dangerous Characters



HTML  Entity





HTML Attribute

<input value="{untrusted}">

non alpha-numeric


This is not safe for complex attributes like href , src , style or event handlers like onclick . Strong allowlist validation must be performed to avoid unsafe URLs like javascript: or data: , along with CSS expressions.

URL Parameter

<a href="/?name={untrusted}">

non alpha-numeric




p { color : {untrusted} };

non alpha-numeric


This is not safe for complex properties like url , behavior , and -moz-binding. Strong allowlist validation must be performed to avoid JavaScript URLs and CSS expressions.


var name = ‘{untrusted}’;

non alpha-numeric


Some JavaScript functions can never safely use untrusted data as input without allowlist validation.


Using JSP

<c:out value=\"${userControlledValue}\"/>
... or ...


Recommendations for Spring tag

Here's how you can output text safely with the Spring tag library:

<spring:escapeBody htmlEscape=\"true\">$
// for data in HTML context</div>
var str = \"<spring:escapeBody javaScriptEscape=\"true\">$
// for data in JavaScript context



You’ve learned what Cross Site Scripting (XSS) in Java is and how to protect your systems from it. We hope you will apply your new knowledge wisely as you code! Feel free to share this with your network. Also, make sure to check out our lessons on other common vulnerabilities.

Want to make a revision on this learning module? Click here to create a pull request!


Featured in:

BLOG: DOM XSS in wix.com 

BLOG: Find JavaScript cyber-vulnerabilities for free with CodeSec

Up Next!

SQL Injection - Java-1

New Icon

SQL injection

Learn about SQL injection and how it affects your Java source code


New Icon


Learn what Log4Shell is and how you can protect your code from this zero-day vulnerability


Client Side Injection

New Icon

Client Side Injection

Learn about Client Side Injection and how it can affect your source code


Server-Side Request Forgery (SSRF)

New Icon

Server-Side Forgery 

Learn about Server-Side Request Forgery (SSRF) and how you can source code from it