Home / Knowledge hub / Stored XSS
Knowledge hub
Stored XSS
Malicious script saved by your app and then served to other people who view it.
What it means
Stored XSS, also called persistent XSS, is cross-site scripting where the attacker's script is saved by your application and then delivered to everyone who loads the affected page. The script may sit in a comment, a profile name, a support ticket, a file name or a chat message.
The attacker does not need to trick anyone into clicking a link. They submit the content once, and your own app does the delivery. The script runs in your origin, with the viewer's session, which is why it is treated as more serious than the reflected kind.
Why it matters
Because the viewer is often someone with more rights, one stored script can reach well beyond the account that planted it. A support agent opens a ticket, an admin reads a user list, and the script acts with their permissions. That turns a low-privilege account into a path to account takeover or to data it should never see.
It also lasts. A reflected bug needs a victim to click each time, but a stored one keeps firing until someone finds and removes the saved content. Cleaning up means fixing the code and finding every record that already holds a payload.
How it shows up
You meet it wherever users write something that other people read: comments, reviews, profile fields, product names, support forms, rich-text editors, imported files and webhooks. Admin screens are the classic blind spot, because they show raw user data to staff and get less review.
The fix is to encode output for the place it lands, in HTML, in an attribute, in JavaScript or in a URL. Validate input too, but do not rely on it. Sanitise rich text with a maintained library and an [[allowlist]] of tags. A content security policy limits the damage if something slips through.
Questions people ask
Stored XSS, answered
What is the difference between stored and reflected XSS?
Stored XSS is saved by the app and served to later viewers. Reflected XSS is echoed straight back from a request, usually from a crafted link. Stored cases need no click from the victim.
Why are admin panels a common target?
Admins view data from many users, often in screens built quickly and with less review. A script that runs in an admin's session acts with admin rights.
Does input validation stop stored XSS?
It helps, but it is not enough. Data is used in many places, and validation at the door cannot know each one. Encode output for its context when it is written to the page.
Can a stored payload be in a file name or an image?
Yes. Any value that comes back to a page can carry a payload, including file names, metadata, filter values and imported spreadsheet cells. Test every field that is shown later.
How do we find stored XSS?
Submit a harmless marker in each field and then browse every page, report and admin screen where it could appear. A test that proves the script ran in a browser is the only reliable confirmation.
Related
Terms that sit next to this one
XSS
An attacker's script running in your pages, in your customers' sessions.
Reflected XSS
A script in a link that your page echoes straight back into the response.
DOM-based XSS
Script injection that happens in the browser's own code, not in the server's response.
Output encoding
Escaping data for its destination so it is shown as text, not run as code.
Content Security Policy
A header telling the browser which scripts a page may load.
Who reads what your users write?
We submit content in your forms and then check every place it is shown, including staff screens, so a stored XSS finding comes with the request, the response and a screenshot. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.