Cross-Site Scripting (XSS)

What is cross-site scripting?

The XSS vulnerability or Cross-site Scripting is a vulnerability, which affects a web application’s front-end.
This vulnerability has been named for the first time in January 2000 by Microsoft and it is one of the most common web application vulnerabilities (Cross-site scripting).
According to the OWASP website, it is present on two-thirds of the web (A7:2017-Cross-Site Scripting (XSS) | OWASP).
It’s pretty simple to understand how it works. A hacker injects some JavaScript code on a web application’s page and when this page is visited, the code gets executed in the user’s browser.

Despite its simplicity, it can be classified into three different forms.


What are the types of cross site scripting?

Stored vulnerability:

An explicit name because malicious content is saved in a database and it appears every time the web application’s page is visited.

Stored Vulnerability
Non persistent vulnerability

Non persistent vulnerability

It uses the HTTP parameters (POST & GET). The server sends it to the user’s browser only once.

Document object model (DOM-based) vulnerability:


Unlike the two others described before, malicious payload is not sent to a server but executed directly by the user’s browser.

Document object model (DOM-based) vulnerability
Document object model (DOM-based) vulnerability


With the stored cross-site scripting attacks, the server stores the script in the database and returns it only when a user’s browser visits the page.
It is impossible for the victim to anticipate an attack before getting the page, making the stored XSS vulnerability probably the most dangerous one in the XSS family.

Reflected and DOM-based XSS attacks
are the opposite of this and must be placed in the settings of a query, especially in the URL.
This means that these two types of XSS attacks can be present in links and are used by hackers in emails. Using a bit of social engineering, hackers can have their victim click on a URL and the malicious script will be executed.

XSS attacks can be performed in many ways, from a

Example of Cross-Site Scripting attack on the web server

1. A chat’s basic use

Let us use the practical case of an XSS attack with a stored XSS because it’s the easiest to understand but has huge implications for a web application and its users. Let us take a basic chat on a web application without particular protection. The page has a box where the message will be appended. There is a form where you can write some text.

We have two users: Loris, the hacker and Paul, the victim.

The goal of Loris is to redirect Paul’s browser on his web server to steal his cookies.

When he clicks on the «Post» button, the message is sent to the server.

When he clicks on the « Post » button the message is sent to the server.
The server will then store it in the database.

When Paul actualizes the chat, the server will send back the message, which will then be inserted in the HTML code.

Loris’s message will be displayed normally on his browser.

2. How to detect cross-site scripting?

 For his next message, Loris will wrap « How are you? » in the <strong> HTML tag which contains a style attribute, to put text in red color.

Same as the first message, the server will store it and then send it back to Paul.

The <strong> tag will be considered as HTML code and put inside the DOM like the other tags.

The message will be displayed in bold and red on the user’s browser. This example was used by Loris to test if the application was vulnerable to XSS. He can now perform a XSS injection with malicious content.

3. What is an XSS attack example?

Loris knows the chat is vulnerable to a stored XSS attack and decides to steal Paul’s cookies.

JavaScript language has got two elements which help him to achieve this goal:

  • document.location that can be used to redirect a browser to another URL.
  • document.cookie that contains cookies of an user on the actual website.
With the code above, Loris can redirect Paul’s browser and his cookies on his own website.

All he has to do now is log on to his website to get Paul’s cookies.

This case represents a simple example of XSS injection but it’s up to the attacker to imagine the technique of his choice to achieve his objective (encoding, obfuscation of the code, etc.).

OWASP best practice example

The Open Web Application Security Project (OWASP) provides a list of rules to apply to protect your web applications:

  • Escaping HTML, CSS and JavaScript characters is probably the most sensible rule to apply. Indeed, not checking user entries in its code will lead them to contain malicious content.
    To implement this rule, you can use functions available in the various programming languages or use bookstores intended for sanitizing the user’s input.
    It should be noted that most modern frameworks like Angular, React or Vue implement this feature natively.

  • Content Security Policy is a computer security standard used to prevent from XSS and code injections attacks (Content Security Policy).
    So integrating a Content-Security-Policy header into HTTP data is also a good way to protect users’ browsers because it lets them use only resources from the server.
    You should notice that Content Security Policy needs to be well configured because it can leak to other security vulnerabilities.

  • Another interesting header and the X-XSS-Protection that automatically filters some XSS attack, it is enabled by default.

You can check all recommendations of the OWASP here: Cross Site Scripting Prevention – OWASP Cheat Sheet Series

How to protect your web application against XSS with R&S®Cloud Protector


To protect a web application against XSS vulnerabilities, R&S®Cloud Protector can do two things:

The Blacklisting strategy

It is used on all levels of protection:
If R&S®Cloud Protector detects a malicious pattern that is normally used to perform a cross site scripting attack, it will block and redirect the request.

The Scoring list

Scoring List is activated on Advanced and High level of protection:

R&S®Cloud Protector will analyze the request and increment a score when it meets a malicious pattern like HTML tag or JavaScript function.
At the end of the analysis, if the score is above the defined limit, the input is considered as an XSS attack so the request will be blocked and redirected.

Scoring list is advantageous if you want to avoid false positives.

Request your 14 days free trial

It takes only 60 seconds to protect your websites and applications.
What are you waiting for?