XSS Complete Attack Guide 2026 — Stored, Reflected, DOM & CSP Bypass

Session Theft

Exfiltrate non-HttpOnly cookies or bearer tokens from localStorage and ride the victim's session.

Account Takeover

Script the app's own "change email / password" flow using the victim's session to lock them out silently.

Keylogging & Phishing

Attach input listeners or inject a fake login form that posts credentials to an attacker endpoint.

Self-Propagating Worms

Stored XSS on a social feature can replicate itself to every viewer — the Samy worm hit a million MySpace profiles in under a day.

DVWA ships XSS modules at three security levels (Low → Impossible), which is perfect for practising filter bypass. The native install gives you a real PHP app you can tweak at the source to see why a filter fails.

Browse to http://localhost/dvwa/setup.php, click Create / Reset Database, log in with admin / password, then open XSS (Reflected), XSS (Stored) and XSS (DOM). Start at DVWA Security = Low and raise it as you go.

The fastest reproducible lab. This docker-compose.yml stands up DVWA, Juice Shop and a tiny reflector you control, each on its own port. Tear it down and rebuild from clean in seconds.

DVWA is on :8081, Juice Shop on :8083, and your callback collector on :9000. Run docker compose down -v to destroy everything including volumes when done.

For CSP-bypass, DOM and cross-origin exfiltration labs, the hosted PortSwigger Academy is unbeatable — free, no install, and each lab's "solve" condition teaches the exact success criterion. Pair it with Burp Suite Community on Kali.

Work the Academy XSS track top to bottom. The reflected/stored/DOM labs back Phases 04–06, and the CSP labs back Phase 08 exactly.

Never start with <script>. Start with a harmless unique string that is unlikely to appear naturally, send it through every parameter, then search the raw response for it. Where and how it is reflected tells you the context — and whether special characters survive.

Reflected and stored XSS hide in more than URL parameters. Enumerate the whole surface before you commit to one injection point.

Against DVWA's reflected module at Low, your marker lands in raw HTML text, so a bare injection works. Raise the level and the context (or a filter) changes, so you switch payloads. These are the canonical one-liners per context.

Use document.domain rather than 1 in the alert — it proves which origin executed the script, which matters when you are chasing a reflection that renders inside an iframe or a different subdomain.

Reflected XSS is only useful if the victim sends the request. For a GET sink that is a URL; for a POST sink it is an auto-submitting form hosted on a page you control. In the lab, your collector service plays the victim-landing role.

DVWA's stored-XSS module is a guestbook that saves name + message. At Low it stores and renders raw HTML. Watch for a maxlength attribute on the input — it is client-side only, so remove it in DevTools or send the request directly through Burp to use a longer payload.

Now load the guestbook in a browser session and watch the hit arrive in your collector: docker compose logs -f collector. Every visitor who renders that page sends their cookie — that is the whole point of stored XSS.

An SVG is XML that browsers execute as markup — including <script> inside it. If an app stores an uploaded SVG and serves it from its own origin (an avatar, a document preview), opening that file is stored XSS. The filename itself is another stored sink if it is echoed into a listing.

Finding DOM XSS is a code-reading exercise. Open DevTools, search the loaded JS for sinks, then trace backwards to see whether any of them is fed by a source you control.

Classic vulnerable pattern: a page reads location.hash and drops it into innerHTML to render a "tab" or search term. Because innerHTML will not run a bare <script> inserted after load, you use an auto-firing event handler instead.

A filter that deletes the literal string script once, or only matches lowercase, or only blocks <script> but not other tags, is defeated by case, nesting, or simply using a different tag. There are hundreds of tags/handlers that execute without the word "script."

Filters often inspect the decoded-once value while the browser decodes again in a different layer. HTML entities, URL double-encoding, and JS escapes let the payload slip past the inspector but reassemble in the browser.

Client-side sanitizers like DOMPurify are strong, but mXSS attacks exploit the gap between what the sanitizer parses and what the browser re-parses after insertion. Markup that looks inert to the sanitizer can mutate into executable markup when the browser normalises it — historically via <template>, <noscript>, namespace confusion (SVG/MathML) and HTML-in-foreign-content quirks.

Every bypass starts with reading the Content-Security-Policy header. Grab it, then check it against a known-weakness checklist.

If the policy trusts a whole domain that happens to host a JSONP endpoint, you can run arbitrary JS from that trusted host — the classic allowlist bypass. If base-uri is unset, a <base> tag can repoint relative script loads to your server.

Nonce-based CSP is strong only if the nonce is unpredictable and never leaked. Two real failure modes: a nonce that is reused across responses (so you can hardcode it), and strict-dynamic, where any script already trusted can create new scripts freely — so one injection into a trusted script's dataflow propagates.

The default demonstration of impact: steal the session. This works only against cookies without the HttpOnly flag, or against tokens stored in localStorage (which is always script-readable — a reason to prefer HttpOnly cookies over JWT-in-localStorage).

More reliable than cookie theft: do not steal the session, use it. Script the application's own account-management flow — fetch the CSRF token from the page, then submit an email change — all inside the victim's authenticated context. This defeats HttpOnly entirely.

XSS gives you the whole DOM, so you can attach input listeners, inject a convincing fake login prompt, or hook the browser into a control framework. BeEF (the Browser Exploitation Framework, pre-installed on Kali) is the standard lab tool for demonstrating sustained post-exploitation of a hooked browser.

The highest-signal hunt is for XSS markup in URL and body fields of inbound requests. Decode first (attackers URL-encode), then match on tag/handler signatures. Expect false positives from WAF test traffic and security scanners — tune by source IP.

A CSP in report-to/report-uri mode turns the victim's browser into a sensor: a blocked inline script generates a violation report. A spike of script-src violations on one page is a strong signal of a live XSS attempt that your policy just blocked.

Successful XSS usually calls home. Hunt egress/proxy logs for beacons to newly-seen external hosts whose requests carry cookie-shaped or base64 query strings, correlated with a Referer from your own app.

XSS spans Initial Access through Collection. Tag your analytics rules with the techniques below so coverage is visible on the ATT&CK Navigator.

Encode untrusted data for the exact context it lands in — HTML body, attribute, JS, URL and CSS each need different encoding. Modern frameworks do this by default; the vulnerabilities appear when developers opt out.

A strict CSP neutralises most injected script even when an encoding bug slips through. The modern recommendation is a nonce-based policy with strict-dynamic, plus Trusted Types to lock down DOM sinks so a raw string simply cannot reach innerHTML.

Round out the defence with the flags and isolation that limit blast radius, then verify the whole stack holds under your Phase 04–08 payloads.