DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Cross-site Scripting (XSS) in Javascript and how to avoid it - vulnerabilities in Javascript
KhalidπŸ₯‘πŸ’» for Ola Campus Pune

Posted on

Cross-site Scripting (XSS) in Javascript and how to avoid it - vulnerabilities in Javascript

Nearly 14 million developers actively use JavaScript. Like multiple other programming languages, javascript is also prone to security vulnerabilities. According to experts, JavaScript is vulnerable because it can easily input query strings into forms to access, steal, or contaminate protected data. Javascript has multiple security vulnerabilities, which leads to attacks like Cross-site Scripting.

In this blogpost we will cover:-

  • Common JavaScript security vulnerabilities
  • What is Cross-site scripting?
  • Types of cross-site scripting?
  • How to be safe from XSS Attacks?

Common JavaScript security vulnerabilities

A security vulnerability is a flaw or a system misconfiguration in which an attacker gains access to the system or the network. Every programming language is prone to security vulnerabilities so does javascript. There are multiple javascript vulnerabilitiesβ€”the best way to prevent them is to adopt formal vulnerability management.

The most common JavaScript security vulnerabilities are:

  • Unintended script execution
  • Session data exposure
  • The unprecedented use of variables
  • Non-Literal-regex
  • Input validation
  • Unintentional user activity

Attackers leverage these vulnerabilities to engage in malicious activities. Some common attacks include cross-site scripting and Cross-Site Request Forgery (CSRF). We will be thoroughly discussing Cross-site scripting in this blog post.

What is Cross-site scripting?

Cross-site scripting (XSS) is a client-side code injection that enables attackers to embed malicious code in a legitimate web page or web application. The code can be designed for multiple reasons.

Possible effects of cross-site scripting are:

  • The attacker gain control of victim’s data,
  • Injection of trojan functionality into the web site.
  • The attacker can compromise their interaction with the web application,
  • The attacker can perform malicious actions,
  • They can access the user’s geolocation, webcam, microphone, and even specific files from the user’s file system.

These are a few of the many problems which can occur.

According to OWASP( an online community dedicated to application and web security), Cross-site scripting is a very common web security vulnerability.

According to Mozilla Docs, Cross-site scripting attacks occurs when:

  • The data enters a Web app through an untrusted source, which in most cases is an unauthorized web request
  • Dynamic content is sent to a Web user without being validated for malicious content

Types of cross-site scripting

We understood in a broad sense how cross-site scripting works but taking a glance on multiple ways or types of XSS is really important. XSS has been divided into 3 categories:-

Reflected XSS

Here the malicious script comes from the current HTTP request. It arises when an application receives an HTTP request that contains a malicious script.

Here is an example:

https://xyz.com/status?message=<script>/*Malicious-Script*/</script>

Enter fullscreen mode Exit fullscreen mode

Stored XSS

Stored attacks are those where the malicious script is stored in the target server permanently, such as in a database, input form or the form of a comment.

Consider an example of a blog page which enables readers to present their views using comments. The attacker can quickly put up a comment using an HTTP request with an injected malicious script.

DOM-based XSS

DOM Based XSS is an advanced version of XSS. It happens when a web application writes data to the Document Object Model without proper sanitization. This enables attackers to execute malicious scripts, typically allowing them to engage with all data illegally.

The Document Object Model is an interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document.

As we now understand now how we can prevent getting into attacks:

How to be safe from XSS Attacks?

XSS attacks are hard to prevent but following steps can be used to prevent getting into such attacks.

According to OWASP, there are multiple ways to prevent XSS Attacks but to summarize most of the solutions, we have to ensure all variables go through validation and are then escaped or sanitized. Any variable passed without a validation is a threat or weakness.

Output Encoding

Output encoding refers to the encoding of the data displayed on the page. Most of the time, data from the user’s input is a potential cause for XSS attacks. The correct encoding of these user inputs, including one through the website’s URL, should be correctly encoded.

In simpler words, output encoding is the process of converting untrusted input into a safe form so it can be displayed as data without executing code in the browser.

Multiple javascript frameworks like React & Angular do an excellent job escaping output by default. As per the documentation, React DOM escapes any values embedded in JSX before rendering them similar to angular's latest version is also escaping output.

But it might be different for general HTML & Javascript;

Some examples of characters and their escaped equivalents are:

For HTML:

Convert & to &amp;
Convert < to &lt; 
Convert > to &gt;
Convert " to &quot;
Convert ' to &#x27;
Convert / to &#x2F;
Enter fullscreen mode Exit fullscreen mode

For Javascript:

Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (XX = Integer)
Enter fullscreen mode Exit fullscreen mode

URLs also need to be encoded; For URLs, only parameter values are encoded, not the entire URL or path fragments of a URL. For encoding URLs for places where we use <a> or <href> do URL encoding, followed by HTML attribute encoding (Reference, OWASP).


 url = "https://site.com?data=" + urlencode(parameter)
<a href='attributeEncode(url)'>link</a>

Enter fullscreen mode Exit fullscreen mode

Let us understand, with an help of an example:-

An attacker attaches this script as a part of a webpage:

   <script>
   harmfulcode
    </script>
Enter fullscreen mode Exit fullscreen mode

The browser converts the encoded script back to this code:

    &lt;script&gt;harmfulcode&lt;/script&gt;

Enter fullscreen mode Exit fullscreen mode

The browser will show this as a part of the webpage without actually running the script

HTML Sanitization

Output encoding in terms of HTML might prevent XSS but will eventually affect the styling of the page. To prevent such cases HTML sanitization is an OWASP-recommended strategy to prevent XSS.

HTML Sanitization will strip down malicious code from a variable and return a safe string.

OWASP recommends DOMPurify for HTML Sanitization. It can be used using the below code snippet-


let clean = DOMPurify.sanitize(dirty);

Enter fullscreen mode Exit fullscreen mode

Input Validations

Input sanitization is a process to prevent malformed data from persisting in the database and triggering malfunction in the workflow of the web application.

There are two approaches to perform input validation:

Client Side

There is good support for client side validation in HTML, we should always leverage the existing functionality provided by the language itself.

For example; ​​ use β€œrequired” attribute & provide type validation in any input field:


<input required name="emailAddress" id="emailAddress" type="email"/>

Enter fullscreen mode Exit fullscreen mode

In the above code snippet, the input provided is required and the type given is email, preventing all such illegal inputs to be entered via the form.

Server Side

Although client-side input validation works perfectly, it can be bypassed with various techniques available. When a request reaches the server, you must again ensure it is valid per the applicable rules. It can be done directly using regular expressions to validate all incoming requests. But other frameworks like Bean Validation (JSR 303) or OWASP ESAPI can also be used.

For a deeper understanding please refer to the OWASP Cheat Sheet

Wrapping up

Cyber security is one of the concerns which is often left out even by senior engineers or experienced Developers. Cross-Site Scripting is an old but most common threat nearly to all users.

There are multiple ways we can prevent getting caught in Cross-site scripting out of which top three are:

  1. Output encoding
  2. Input Validation
  3. HTML Sanitization

We look forward to sharing more of our workflows in the coming days. If you have some feedback or have found this blog post of your interest, do connect with us!

Top comments (0)

12 Gorgeous UI Components for Your Design Inspiration

>> Check out this classic DEV post <<