Stored Cross-site Scripting (XSS) :Understand and Find the Way How to Protect Yourself

The Cross-site Scripting (XSS) vulnerability refers to code injection attack in client-side where the malicious scripts or payloads can be executed by an attacker into a trusted website.

While navigating to the vulnerable web page, an end user can find the malicious script or the malicious payload as a part of the web page. For this reason, the end user will end-up executing the malicious script unintentionally once the web page is viewed in a browser.

While XSS attack can be exploited within JavaScript, ActiveX, Flash, and VBScript, but the most widely used programming language is JavaScript – because JavaScript is much more familiar as well as compatible to most browsing experiences.

Cross-site Scripting can be categorized into three types:

  1. Stored XSS or Persistent XSS
  2. Reflected XSS or Non-Persistent XSS
  3. DOM-based XSS

Among these three, the most dangerous type of XSS is Stored XSS. Because the inputs injected by the attacker is stored and embedded later into the vulnerable web application (say in the application's database) permanently in an unsafe way.

The attacker who is inserting the malicious payloads can be served back to any other users unknowingly who will be browsing the pages of the web application and can also be executed later in their context. Therefore the end users do not require to click on a malicious link in order to run or execute the script, simply just he/she needs to visit the affected page of the web application once in a browser.

Stored XSS flaws are more serious than Non-Persistent vulnerabilities as it does not need any isolated delivery mechanism for reaching out to the target users. Depending on the affected web page, even during normal use of the application, ordinary users may be exploited.

An example of Stored XSS:
Injecting any kind of malicious payload by an attacker in a feedback field for an article permanently.


There are a lot of impacts of XSS vulnerability that varies from application to application. A victim faces a variety of problems that affect the web application in many different ways that range in severity from an annoyance to the full compromise of the application.

The most severe Stored XSS attacks involve:

  • Disclosing the victim’s cookie information.
  • Hijacking the victim’s session using stolen session token.
  • Impersonating the end user and take over the account.
  • Disclosing the files of an end user
  • Installing the Trojan horse programs
  • Redirecting the victim to some other malicious web site or web page
  • Modifying presentation of content. 
  • Disclosing any other kinds of sensitive data, CSRF attacks and more.

When an application is not able to handle the data provided by the end user properly, by providing valid HTML via a parameter value and by injecting their own content into the web page, an attacker may compromise the entire application.

If the end user has the rights of the administrator, it might even lead to code execution on the server, depending on the application as well as the privileges of the account.

How it happens 

  • Login to the application using the valid credentials.
  • Find out any vulnerable input field inside the vulnerable website or web application.
  • Try injecting the below-mentioned code in the 'Comment' field: <script> alert ("Stored XSS occurs") </script>
  • After clicking on the 'Submit' button, the above JavaScript code gets executed which will pop up an alert box displaying the message 'Stored XSS occurs' as shown in the below figure.

In the similar way, attacker can also inject the codes like:

<input onmouseover=alert(document.cookie)>
<img src="AA" onerror=alert(123)>

These will pop up alert boxes displaying the cookie value, domain name, 123 respectively.

Hence, this proves that the application is vulnerable to Stored Cross-site scripting.


  • In order to prevent Stored XSS attacks, the best way is to handle the input securely in both client-side and server-side code in a proper manner before it gets stored permanently on the web server. In most of the cases, encoding should be performed whenever any input provided by the user is included in a page. But sometimes, validation needs to be implemented instead of encoding.
  • When secure input handling does not work, at that time Content Security Policy comes into play to provide an additional layer of defense.
  • At present, most modern web browsers are having an inbuilt XSS filter which basically does not allow any kind of malicious page to load just to prevent XSS attacks. This kind of filter is mainly used to minimize the risk of occurring XSS vulnerabilities.
  • Additionally, in order to improve the security of the website against XSS attacks, it is recommended that the following header can be added to that particular site: X-XSS-Protection: 1; mode=block


Authored By - Mafiza Khatun
TCS Cyber Security Practice

Rate this article: 
Average: 1.2 (1144 votes)
Article category: