Day 6: OWASP Top 10 2021 – #3 Injection: Cross-Site Scripting (XSS) Vulnerability

What is Cross-Site Scripting?

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. Its vulnerabilities normally allow an attacker to masquerade as a victim user, carry out any actions that the user can perform, and access any of the user’s data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application’s functionality and data.

How does Cross Site Scripting (XSS) work?

Cross-site scripting works by manipulating a vulnerable website’s source code/storage system so that it returns malicious JavaScript to users. When the malicious code executes inside a victim’s browser, the attacker can fully compromise their interaction with the application by stealing session cookies, user credentials, tokens, secrets, etc.

Types of Cross Site Scripting (XSS)


1. Reflected XSS: The malicious script comes from the current HTTP request when injected into the source code of the application. Reflected cross-site scripting arises when an application receives data in an HTTP request and includes that data within the source code which initiates that immediate response in an unsafe way.


2. Stored XSS: The malicious script comes from the website’s database which eventually gets executed in the user’s browser. Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way. This type of XSS happens when the server saves your supplied input somewhere into the server i.e Database, cache server.


3. DOM-based XSS: The vulnerability exists in client-side code rather than server-side code. In DOM-based XSS, the malicious user input goes inside the source and comes out of the sink. DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM. This is a source and sinks process, the user input which can be any malicious code that goes into the source and comes out from the sink results in a DOM XSS.

Effects of Cross Site Scripting (XSS)
  • Impersonate or masquerade as the victim user.
  • Carry out any action that the user can perform.
  • Perform virtual defacement of the website.
  • Read any data that the user can access.
  • Capture the user’s login credentials.
  • Inject Trojan functionality into the website.
How to Prevent Cross Site Scripting Vulnerability

Filter input on arrival:  At the point where user input is received, filter as strictly as possibly based on what is expected or valid input.

Use appropriate response headers: To prevent XSS in HTTP responses that aren’t intended
to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-
Options headers to ensure that browsers interpret the responses in the way you intend.

Encode data on output: At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.

Content Security Policy: As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

Implementing WAFs: A web application firewall (WAF) can also be used to stop this type of attack, developers can implement WAFs and properly configure them to block certain malicious user inputs.

References To Get More Understanding of Cross Site Scripting (XSS)

This will be all for the Day 6 post. Hope you enjoyed it, kindly let me know in the comments section. Be sure to check out other blog posts of interest or come back tomorrow for the next day’s post. 😊