Stored XSS (Cross-Site Scripting) occurs when malicious scripts are permanently stored on target servers and later displayed to users who access affected pages. This type of XSS is particularly dangerous as it affects all visitors to the compromised page. Prevention requires proper input validation, output encoding, and content security policies.
Stored cross-site scripting, also called persistent XSS, occurs when an application accepts attacker-supplied content, saves it, and later serves it to other users without proper encoding. The malicious script is written once, into a comment field, a product review, a forum post, a user profile, or a support ticket, and it then executes in the browser of every visitor who loads the affected page. Unlike reflected XSS, no crafted link or per-victim social engineering is needed; the payload waits on the server and fires automatically. Because the injected markup becomes part of the page's normal content, it can persist for as long as the record exists and keep infecting new viewers.
Stored XSS is the most dangerous XSS variant because it is self-propagating and touches everyone who views the poisoned page. A payload placed in a popular thread or a shared profile can run in thousands of sessions, and if it lands somewhere an administrator views, it can escalate to full account or application takeover. Running under the site's origin, the script can steal session tokens and non-HttpOnly cookies, capture keystrokes and form data, act as the victim, or worm itself into more records. Historic XSS worms spread exactly this way, adding themselves to each profile they touched and infecting new users on every view.
Defense is primarily server- and code-side: validate and sanitize input on the way in, encode output for its exact context on the way out, and clean any rich HTML with a vetted sanitizer before it reaches the DOM. A Content Security Policy limits what an injected script can do even if one slips through. cside does not replace these controls for your own application code. Where it helps is the browser-runtime layer: it routes third-party scripts through a Script method, analyses the JavaScript payload that actually runs, can block malicious behaviour such as data exfiltration in real time, and retains forensic records that support PCI DSS 6.4.3 and 11.6.1.
Because the payload is saved server-side and served to everyone who opens the affected page, it needs no per-victim link or click. One injection can run in every visitor's session, and if an admin views it the attacker may gain elevated access, giving stored XSS a far larger blast radius.
No. The vulnerability is about how content is rendered, not where it is kept. If stored data is later inserted into a page as HTML without encoding or sanitization, it will execute. Markdown can even add risk if it permits raw HTML or unsafe links, so output must still be sanitized.
We answer client-side security questions every day. Bring yours.