Stored XSS
What is Stored XSS?
Stored XSSA persistent cross-site scripting flaw where attacker-supplied script is saved on the server and later executed in every visitor's browser.
Stored XSS (also called persistent XSS) occurs when an application accepts untrusted input, saves it in a database, file system, log, or other backing store, and later renders it into HTML without proper output encoding. Because the payload lives on the server, every user who views the affected page automatically executes the script, making it one of the highest-impact web flaws. Typical targets include comment fields, user profiles, product reviews, and admin dashboards that display log entries. Defenses include context-aware output encoding, a strict Content Security Policy, input validation, and sanitization libraries such as DOMPurify.
● Examples
- 01
A blog comment containing <script>fetch('/api/me').then(...)</script> that runs for every reader.
- 02
Attacker stores a payload in their profile name, executing in the admin panel that lists users.
● Frequently asked questions
What is Stored XSS?
A persistent cross-site scripting flaw where attacker-supplied script is saved on the server and later executed in every visitor's browser. It belongs to the Attacks & Threats category of cybersecurity.
What does Stored XSS mean?
A persistent cross-site scripting flaw where attacker-supplied script is saved on the server and later executed in every visitor's browser.
How does Stored XSS work?
Stored XSS (also called persistent XSS) occurs when an application accepts untrusted input, saves it in a database, file system, log, or other backing store, and later renders it into HTML without proper output encoding. Because the payload lives on the server, every user who views the affected page automatically executes the script, making it one of the highest-impact web flaws. Typical targets include comment fields, user profiles, product reviews, and admin dashboards that display log entries. Defenses include context-aware output encoding, a strict Content Security Policy, input validation, and sanitization libraries such as DOMPurify.
How do you defend against Stored XSS?
Defences for Stored XSS typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Stored XSS?
Common alternative names include: Persistent XSS, Type-2 XSS.
● Related terms
- attacks№ 240
Cross-Site Scripting (XSS)
A web vulnerability that allows attackers to inject malicious scripts into pages viewed by other users, executing in the victim's browser under the site's origin.
- attacks№ 912
Reflected XSS
A non-persistent XSS where attacker-controlled input from a request is immediately reflected into the response and executed in the victim's browser.
- attacks№ 347
DOM-Based XSS
An XSS variant where the injection and execution happen entirely in the browser as client-side JavaScript writes untrusted data into a sink without sanitization.
- appsec№ 214
Content Security Policy (CSP)
An HTTP response header that tells the browser which sources of scripts, styles, frames and other content are allowed, limiting the impact of XSS and data-injection attacks.
- appsec№ 773
Output Encoding
Transforming untrusted data into a form that is safe for a specific output context — HTML, JavaScript, URL, SQL, shell — so it cannot break out and execute as code.
- appsec№ 538
Input Validation
The server-side check that every untrusted input matches an expected type, length, range, format and value set before being processed by the application.
● See also
- № 104Blind XSS