Cybersecurity glossary

What is Stored XSS?

Learn what stored XSS is, how persistent scripts infect other users, where payloads are commonly saved, and how to prevent stored cross-site scripting with encoding and CSP.

Application securityUpdated July 20, 2026
Also known asPersistent XSSPersistent cross-site scriptingStored cross-site scripting

Definition

Stored XSS (persistent cross-site scripting) is a vulnerability in which attacker-supplied script is saved by the application—in a database, CMS, comment field, or other storage—and later delivered to other users’ browsers as if it were trusted content.

Why stored XSS is especially damaging

Reflected XSS often needs a victim to click a malicious link. Stored XSS waits inside the application. Every user—or every admin—who loads the infected page becomes a victim automatically.

That persistence makes stored XSS a favorite path to session theft, account takeover, and malware delivery inside trusted origins.

How stored XSS works

1

Attacker submits a payload

Script or HTML is entered into a field the application will store.

2

Application saves it

The payload lands in a database, object store, or CMS without safe handling.

3

Other users request the content

Profiles, feeds, tickets, or admin panels render the stored value.

4

Browser executes attacker script

Because the page is same-origin, the script can access cookies (if not HttpOnly), DOM, and APIs.

5

Impact spreads

Session theft, fake UI, further XSS posts, or privileged admin actions.

High-risk storage surfaces

User-generated content

Comments, reviews, bios, chat messages, and forum posts.

Admin / support tools

Tickets that display attacker text to privileged staff.

File uploads

SVG, HTML, or markdown rendered inline unsafely.

Configuration fields

Site titles, email templates, and custom CSS/JS settings.

Defenses

ControlRole
Output encodingPrimary fix—encode for HTML, attr, JS, URL contexts
HTML sanitizationOnly when rich HTML is required; use maintained libraries
CSPReduces impact of escaped injection bugs
HttpOnly cookiesLimits trivial cookie theft via document.cookie
Upload hardeningServe user files with safe Content-Type and disposition
  • Encode on output for every context where stored data is rendered.
  • Prefer plain text or markdown with safe renderers over raw HTML.
  • Sanitize rich text with a well-maintained allowlist sanitizer.
  • Deploy a strict CSP as defense in depth.
  • Mark session cookies HttpOnly and Secure.
  • Isolate untrusted HTML in sandboxed iframes when necessary.
  • Review admin UIs that display user content with extra scrutiny.
  • Include stored XSS cases in QA for every new user-content feature.

The practical takeaway

Stored XSS plants scripts in your application so future viewers execute them under your origin. Encode on output, sanitize carefully when HTML is required, and assume every stored field may one day be hostile.

If users can save content that other users see, you have a stored XSS surface—design for it from day one.

Related security terms

Frequently asked questions

What is stored XSS in simple terms?

An attacker saves a malicious script in your app (comment, profile, ticket). Everyone who later views that content runs the script in their browser.

How is stored XSS different from reflected XSS?

Stored XSS persists on the server and hits many victims over time. Reflected XSS needs a crafted request each time and usually one victim per click.

Why is stored XSS often worse?

It can worm through an application, infect admins automatically, and steal sessions without phishing each victim individually.

Where do stored XSS payloads hide?

Comments, display names, support tickets, product reviews, uploaded SVG/HTML, markdown fields, and admin configuration values.

How do you prevent stored XSS?

Context-aware output encoding, safe HTML sanitizers when rich text is required, CSP, and HttpOnly cookies—plus input validation as defense in depth.

Does sanitizing on input alone fix stored XSS?

Risky. Prefer encoding on output for the correct context. Input sanitization for HTML is hard to get right and often incomplete.

References

Explore authoritative guidance and frameworks related to stored xss.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary