Search Go hack yourself with Detectify

An EASM blog from Detectify

OWASP TOP 10: Cross-site Scripting - XSS

May 13, 2016

Update: On the OWASP Top 10 2021 proposed, Cross-site scripting (XSS) was moved from the top of the OWASP list as a stand-out vulnerability, into the Injection grouping. It’s no longer top of the OWASP list, however injection still impacted 94% of the web apps testing during the evaluation.

Cross-site scripting is one of the most common OWASP vulnerabilities, affecting both small businesses and large corporations. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series. A proof of concept video is found at the end of the article


Cross-site scripting is a type of attack that can be carried out to compromise users of a website. The exploitation of a XSS flaw enables the attacker to inject client-side scripts into web pages viewed by users.

It is often assumed that cross-site scripting means JavaScript, but could also include e.g. VBScript.


Cross-site scripting is often said to be the most common vulnerability, and many sites are affected. This includes small local sites as well as giants like Google. In 2016, Cross-site scripting was among the top 5 most common critical vulnerabilities discovered by the Detectify scanner.

Potential impact of cross-site scripting vulnerabilities

Due to the ability to execute JavaScript under the site’s domain, the attackers are able to:

  • View anything the user sees, and steal sensitive information by doing so.
  • Change what the user sees and manipulate information.
  • Basically do everything a normal user could, as the attacker can both see and change anything presented to the user. This includes bypass of all CSRF-protections. To put it into context; if the attacker successfully tricks an admin to execute the XSS, the attacker can do everything an admin could do.
  • Do things that the vulnerable domain has access to do, which can buy access to the user’s webcam, microphone or location.


Any source of data that the browser ends up rendering is a potential attack vector. This means there are many different potential ways to exploit the site, and the risk therefore increases.

Cross-site scripting is considered one the easier to understand vulnerability types. With that said, there is no limits on how to complicated it can be to exploit under different circumstances and protections.

Well-known events

One of many great examples where XSS is used as a part in a longer chain of attacks is the following:

One of the most famous attacks is the attack called Samy. Within 20 hours, over a million users had fallen victim for the vulnerability. This happened in 2005, but even today there are several examples showing that XSS is a vulnerability type to keep an eye on.

Another well-known attack, similar to Samy, is the only two years old attack on TweetDeck. They had a cross site scripting-vulnerability, and everyone who fell victim for it retweeted it. This means it quickly turned into a worm that spread itself.

How to discover cross-site scripting

It is possible to categorise cross-site scripting vulnerabilities in different subcategories. One of those are the ones that only lay in the client, where the site owner would need to analyze all the JavaScript to identify how all data that originates from a user flows. At first, it is easy to think about only the normal places, but after a while it is obvious that there are many more vectors than one would initially think about.

Then there is reflected cross-site scripting, which is when page simply reflected some kind of input from the user. E.g.:

<?php echo $_GET[“g]; ?>

However, there are also stored cross-site scripting vulnerabilities, where the server instead echoes something stored in the database.

This makes it hard to automatically analyze everything, as an attacker would benefit from being able to reverse track every output to see where the data comes from and how it has been manipulated on its way there.

In short, it can be concluded that for discovering the first mentioned type the site owner would need to follow the dataflow all through JavaScript to see how it treats user input. In this case, user input can be default variables in JavaScript such as


as well as e.g.


For the second mentioned vulnerability, the site owner needs to look for every location where data is printed, and identify how it got treated on its way there as well as where the data originates from. In real life examples, it is not uncommon to see a combination of these vulnerability types.

How Detectify can help

Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including cross-site scripting and other OWASP Top 10 vulnerabilities, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable » 

Code example of a vulnerable application

Assume a site does has a search box with code as the following:


// Code for performing the actual search

} else {

echo "Could not find any pages when searching for ".$_GET['query'];


would therefore result in:

 Could not find any pages when searching for test

This would output the user input straight to the HTML-document. As such, if a user would give HTML as input the browser would be required to render that.

Example, if we were to access<script>alert(1)</script>

it would result in the following that the browser would try to render.

 Could not find any pages when searching for <script>alert(1)</script>

That is perfectly valid HTML, and the script will get executed.

To show the danger of this, imagine an attacker getting the user to click a link as the following:<script>document.InnerHTML += "<img src='"+document.cookie+"'>"</script>

It would result in this, which sends the cookies to the attacker. If there for example were sessions id, an attacker could hijack the session.

Could not find any pages when searching for <script>document.InnerHTML += "<img src='"+document.cookie+"'/>"</script>   

Cross-site scripting remediation

Potentially dangerous characters need to be sanitized, or escaped. How this is done varies depending on the context, and for most cases the article in our knowledge database would be sufficient.

The application should also be developed with the risk of XSS in mind, making it as little harmful as possible if it were to exist a XSS vulnerability. Two of the most well-known methods for this is HttpOnly and CSP. More information about HttpOnly can be found here, while CSP is something that we have not written that much about.

Cross-site scripting attack demo

Read more

Related remediation documents:




Does your website pass the OWASP Top 10 test? Sign up to run a OWASP vulnerability scan