How to Prevent Cross-Site Scripting (XSS)?

Research Team
 December 7, 2021

What is Cross-Site Scripting (XSS)?

Cross-site scripting is a security vulnerability that can damage an entire website or application. XSS is so damaging that security experts include it in the list of top 10 vulnerabilities. Even the OWASP considers it amongst the top security vulnerability.

Moreover, cross-site scripting is a security threat that has been around seven years. Even in 2019, it was amongst the top 3 reported vulnerabilities.

Cross-site scripting (XSS) is a specialized method to compromise a website. The attacker attaches malicious scripts to the victim’s website in this method. Generally, the process involves sending malicious scripts to the victim’s application.

It is a common security threat in web applications. It can take place at any point in an application where the server takes input from the browser and creates output without authenticating the data at first.

The browser-side script makes the website susceptible to this vulnerability on the flip side. Thus, allowing an attacker to exploit this security flaw even the user doesn’t interact with the web application.

Attackers exploit XSS vulnerability by creating malicious code passed to another user. After that, the malicious script is executed by an unsuspecting browser.

Since the web application server response often comprises scripts, malicious scripts will have the same accessibility as a legitimate script. Eventually, an attacker can gain access to session tokens, cookies, and even secret information the browser has access to on that particular website.

Likewise, a hacker can even alter the HTML page content.

Types of XSS Attacks

There are three main types of XSS attacks.

DOM-based

An application becomes susceptible to DOM XSS when it contains client-side Javascript that process data from an untrusted source in an unsecured manner. Generally, it does so by transferring data back to the DOM.

In the below code example, the application uses some Javascript to read values from an HTML5 input field. After that, it will write that value into the HTML5 element.

Code Example
<p>var input = document.getElementById("input").value;</p>

<p>var results = document.getElementById("results");</p>

<p>results.innerHTML = 'You are looking for: ' + search;</p>

If an attacker somehow manages to gain access to the value of the input field, they can create a malicious value. As a result, they can execute their Javascript code.

You are looking for: <img src= ‘121 onerror=’/* Bad Response……… */ ’>

In some cases, the attacker exploits the input field from the HTTP request. For instance, the URL query string parameter allows an attacker to attack a system using a malicious URL.

Stored

Stored XSS executes when an application receives data from an untrusted source. Eventually, it includes that data in its HTTP response insecurely.

The desired data will then be submitted via an HTTP request to an application. For instance, comments on a blog post or shipping details of customer orders.

In other cases, data might arrive from other un-credible sources. For instance, a webmail application displays messages it received via SMTP or a marketing application that displays social media posts.

Here is a quick code-based example of stored XSS vulnerability. A message board application allows users to submit an application that other users can see.

Code Example
<p>Hello, this is my first message</p>

Generally, an application doesn’t perform any data authentication. So, an attacker can easily create a message that can compromise an entire application.

<p> <script>/* some wrong stuff here */ </script> </p>

Reflected

Many real-world applications receive data in the form of HTTP requests that make them vulnerable to reflected XSS. After that, it includes that data within an immediate response in an insecure way.

Here is the simplest code example of a reflected XSS attack.

https://malicious-website.com/status?message=Everything+is+Ok.

<p>Status: Everything is completely Ok</p>

Most applications do not process incoming data, so an attacker can easily create an attack like:

https://malicious-website.com/status?message=

<script>/* +Malicious + code + here….. + */</script></p>

<p> Status: <script>/* malicious code here……*/</script></p>

If the user visits the URL created by a hacker, an attacker will then be able to execute malicious code in the user’s browser.

Prevention

So far, we have discussed XSS and how to prevent it? Preventing XSS vulnerability is a trivial task. However, we can take some steps to offset the potential threat of this vulnerability.

Education and Awareness in an organization

To prevent XSS vulnerability, you first have to make sure your development, testing, and deployment team knows the security fault lines. Eventually, they can adapt better coding practices. For instance, developers can adapt better encoding techniques for an application environment like Javascript.

Moreover, you should conduct security awareness sessions in your company to train your technical staff. So, they can withstand any cyberattack in the foreseeable future.

Do Not Blindly Trust User Input

Any user input that could be used as an HTML output makes your application vulnerable to XSS attack. As a security practitioner, you should treat all the inputs equally, whether from an authentic user or the public.

Escaping/Encoding Technique

Use the proper escaping/encoding technique, particularly where the user input is likely to be used. For instance, HTML escape, Javascript escape, CSS escape, and URL escape.

Sanitize the HTML

If the user input contains HTML, you cannot escape/encode it because it could break the valid tags. We strongly recommend you use a trusted third-party library to sanitize the HTML in this situation.

Furthermore, you should choose a library compatible with your development language. For instance, SanitizeHelper for Ruby on Rails.

Implement Content Security Policy

To mitigate the potential threat of XSS attack, we strongly recommend using a Content Security Policy. Leveraging the CSP, you can declare the dynamic resource-loaded depending on the request source.

Scan Regularly

XSS vulnerability might hurt your application due to ignorance of your developers or injection of third-party libraries. For this reason, you must scan your web application using a web vulnerability scanner.

Use Appropriate Response Header

To prevent XSS in HTTP responses that do not contain any HTML or Javascript code, you must use the Content-Type or X-Content-Type option. Therefore, you can make sure that browsers do not misinterpret the responses.

External Resources

To learn how to ensure software development security, read more in our knowledge base.