Cross-Site Scripting (XSS): Reflected, Stored, and DOM-Based, Explained

Cross-site scripting still gets treated as one bug when it's really three different vulnerability classes with different root causes, different places they hide, and different fixes. CWE-79, MITRE's own weakness definition, covers all three under one number, "Improper Neutralization of Input During Web Page Generation", but a scanner report that just says "XSS found" without saying which kind tells a developer almost nothing about where to actually fix it.

Reflected XSS: the request round-trip

Reflected XSS is the simplest form: unsanitized input from the current request (a query parameter, a form field, a URL fragment) gets echoed straight back into the page's HTML in the response, with no storage step in between. A search page that prints "No results for" followed by the search term, reflecting that term back verbatim and unescaped, is the textbook case. It requires tricking a specific victim into clicking a crafted link, which makes it lower-severity than the stored variant in most scoring models, but it's also the most common kind found in a typical web assessment, because it shows up anywhere user input gets echoed back without a framework's auto-escaping doing the work.

Stored XSS: the one a WAF can't see coming

Stored XSS is more dangerous because the payload is saved server-side, in a database field, a comment, a user profile name, and served back to every visitor who views that content, not just someone who clicked a crafted link. This is exactly why a WAF alone is an incomplete defense: a web application firewall inspects requests coming in, but a stored payload was often submitted long before, through a form that looked completely benign at submission time (a support ticket subject line, a display name, a file's metadata). By the time it's rendered back out to another user, there's no "request" for the WAF to have inspected, the vulnerability is in how the output gets rendered, not in the request that stored it.

DOM-based XSS: the one that never touches the server

The third kind doesn't require the server to be vulnerable at all. DOM-based XSS happens entirely in the browser, when client-side JavaScript takes something attacker-controllable, location.hash, document.referrer, a URL parameter read via URLSearchParams, and writes it into the DOM through a dangerous sink (innerHTML, document.write, eval) without sanitization. A server-side scanner that only inspects HTTP responses can miss this entirely, because the vulnerable code path never appears in the server's rendered output, it only exists in client-side JavaScript execution, which is exactly the kind of finding manual testing catches that automated scanning consistently misses.

What stops each one

• Output encoding, contextually correct for where the data lands (HTML body, HTML attribute, JavaScript string, URL), the single most reliable fix, and the one most modern frameworks (React, Angular, Vue) do automatically unless a developer explicitly opts out with something like dangerouslySetInnerHTML
• A real Content-Security-Policy with no unsafe-inline in script-src, see our piece on HTTP security headers that actually matter for what a CSP does and doesn't cover
• Treating every client-side read of location, document.referrer, or postMessage data as untrusted input, the same way server-side request parameters already are
• HttpOnly on session cookies, so a successful XSS still can't directly exfiltrate the session token even if the payload executes

Why this still shows up in mature codebases

Modern frameworks' auto-escaping has made classic reflected XSS rarer than it was a decade ago, but it hasn't eliminated the class, it moved where it hides. dangerouslySetInnerHTML, a template engine's "raw" or "safe" output filter, a legacy jQuery .html() call migrated forward from an older codebase, or a genuinely new DOM-based sink in client-side routing logic are where it shows up now. Our Web & API Security Testing engagements specifically test all three variants, not just the reflected case a basic scanner catches, and our Secure Code Review service looks for exactly these dangerous-sink patterns before they ship. For the access-control class of finding that usually sits right alongside XSS in a real report, see broken access control and IDOR.