Cross-Site Scripting (XSS) is the injection of attacker-controlled JavaScript into a page that the victim's browser trusts — so the malicious code runs with the full privileges of that site, in the victim's own session. If you've just come from the CSRF course, this is the bug that kept getting flagged as "defeats every CSRF defence." This chapter explains exactly what XSS is, why it's so powerful, and why it sits near the top of every web-security risk list.

The Core Idea: Untrusted Input Becomes Code

XSS happens when an application takes data from an untrusted source (a URL parameter, a form field, a stored comment) and inserts it into an HTML page without properly neutralizing it, so the browser interprets it as code rather than data. The browser can't tell the difference — to it, a <script> the developer wrote and a <script> an attacker injected look identical.

The application meant to display the name as text; because it didn't encode the input, the browser parsed it as a script element and executed it. That single failure — treating input as code — is the root of all XSS.

Why It's So Powerful: It Runs In-Origin

The injected script executes same-origin — as if the site itself wrote it. That means it inherits everything the legitimate page can do:

• Read the DOM — every piece of data on the page, including things the user typed.
• Read non-HttpOnly cookies and localStorage/sessionStorage — session tokens, app state.
• Make same-origin requests with the user's session — and read the responses (unlike CSRF).
• Modify the page — inject fake login forms, deface content, capture keystrokes.
• Act as the user — perform any action the user could, invisibly.

XSS vs CSRF — The Capability Gap (Bridging the Last Course)

If you took the CSRF course, this comparison crystallizes why XSS is the more dangerous of the two:

A Concrete Impact: Session Hijacking

The classic demonstration is cookie theft. If the session cookie isn't HttpOnly, an injected script can exfiltrate it, letting the attacker impersonate the victim entirely:

With the session cookie, the attacker logs in as the victim — no password needed. (Chapter 5 covers the full range of impacts; HttpOnly cookies, Chapter 10, blunt this specific trick but not XSS in general, since the script can still act as the user directly.)

Why XSS Persists

XSS has been a top web vulnerability for two decades. It endures because:

• Every dynamic page is a candidate — anywhere user input reaches the page, a missed encoding creates a hole.
• The defences are context-dependent — "escaping" means different things in HTML vs an attribute vs JavaScript (Chapter 3), and getting the context wrong reopens it.
• Modern frameworks help but don't eliminate it — React/Vue/Angular auto-escape by default, which slashed XSS rates, but their escape hatches (dangerouslySetInnerHTML, v-html) put it right back (Chapter 9).

Hands-On Exercises

All XSS shares the same root cause (Chapter 1: input treated as code), but it's classified by where the malicious input comes from and how it reaches the page. The three types — Reflected, Stored, and DOM-based — differ in delivery, persistence, and which part of the stack fails. Knowing the type tells you where to look and how to fix it.

Type 1: Reflected XSS

The payload is included in a request (typically a URL parameter), and the server immediately reflects it back in the response without encoding. It isn't stored — it only affects whoever makes that specific request, so the attacker must deliver the crafted URL to the victim (a link in an email, a message, a malicious ad).

When the victim clicks the link, the server echoes the script into the response and the victim's browser runs it. Reflected XSS is the most common type and requires the victim to interact with an attacker-supplied request.

Type 2: Stored XSS

The payload is saved on the server (in a database, comment, profile field, log) and later served to every user who views the affected page — no special link required. This makes it the most dangerous type: one injection can hit thousands of victims automatically.

Every visitor to the comments page executes the attacker's script in their own session, with no action beyond visiting a normal page. Stored XSS on a high-traffic page is how XSS worms spread (Chapter 5).

Type 3: DOM-Based XSS

The vulnerability is entirely client-side: the page's own JavaScript takes attacker-controllable input (from the URL, location.hash, etc.) and writes it into the page through a dangerous "sink" — the malicious data never needs to touch the server.

The Key Split: Server-Side vs Client-Side

Severity, Roughly

• Stored — generally highest: persistent, hits all viewers automatically, no per-victim delivery, can self-propagate (worms).
• Reflected — common and serious, but needs the victim to follow an attacker's link, limiting reach per attack.
• DOM-based — severity varies, but dangerous because it bypasses server-side defences and is easy to miss; can be reflected-like or stored-like depending on the source.

These are tendencies, not rules — a reflected XSS on a bank's login page can be more damaging than a stored XSS in an obscure admin note. The next three chapters take each path deeper, starting with the injection contexts that determine how a payload must be shaped.

Hands-On Exercises

The same input can be harmless in one place and a script-execution hole in another. Where untrusted data lands in the page — its context — determines which characters are dangerous and therefore how it must be encoded. This is the most important technical idea in XSS defence: encoding is context-dependent, and getting the context wrong reopens the hole even when you "escaped" the input.

The Five Contexts

A browser parses a page through several sub-grammars, and untrusted data can be injected into any of them. Each has different "breakout" characters:

Context 1: HTML Body

Data between tags. The breakout is simply introducing a new tag — the canonical XSS. Encoding < > & to entities neutralizes it (Chapter 1's example).

Context 2: HTML Attribute

Data inside an attribute value. The attacker doesn't need a new tag — they just break out of the quotes and add an event-handler attribute:

Context 3: Inside JavaScript

Data placed into a script block (e.g. a server templating a value into JS). This is the most dangerous context — the attacker is already in a script and only needs to break the string literal:

Context 4: URL

Data used as a URL, typically in href or src. Even with quotes intact, the attacker can supply a dangerous scheme:

Attribute-encoding the quotes isn't enough here — javascript: contains no special HTML characters. The fix is to validate the scheme: allow only http:, https:, mailto: (an allowlist), and reject javascript:, data:, vbscript:. Then URL-encode the data.

Context 5: CSS

Data placed into a stylesheet or style attribute. Historically expression() (old IE) ran JS; today the main risks are url() exfiltration, breaking out of the CSS context into HTML, and UI-redress tricks. Untrusted data in CSS should generally be avoided or strictly allowlisted (e.g. a fixed set of colour names), never freely templated.

The Central Lesson: Match the Encoder to the Context

A practical corollary: nested contexts compound. A value inside an onclick handler is in a JS context inside an HTML-attribute context inside HTML — it needs JS encoding then attribute encoding. These multi-layer cases are exactly why "just use the framework's auto-escaping" (Chapter 9) is the safer real-world advice than hand-encoding.

Hands-On Exercises

A Payload Has Two Jobs

Every XSS payload does two things: (1) break out of the data context into a code context (Chapter 3), and (2) execute the attacker's JavaScript. The famous alert(1) is just a harmless stand-in for job 2 used to prove execution — the real interest is job 1, the breakout, because that's what the application's encoding is supposed to prevent.

You Don't Need <script> — Event Handlers

A common misconception is that XSS requires a <script> tag. In reality, any element with an event handler can run code, and these often survive naive filters that only strip <script>:

The <img onerror> and <svg onload> vectors are the workhorses precisely because they need no script tag and fire automatically. There are dozens of HTML elements with auto-firing event handlers — which is the first hint that "block the dangerous tags" is unwinnable.

Why Blocklists Fail: The Bypass Zoo

Developers often try to filter XSS by removing "bad" strings like <script> or javascript:. Attackers have an enormous repertoire of equivalent encodings the browser still executes:

Polyglots: One Payload, Many Contexts

A polyglot is a single payload crafted to execute across multiple injection contexts at once — useful to attackers probing an unknown injection point, and to testers wanting one string that fires whether it lands in HTML, an attribute, or JS. They look cryptic because they're engineered to be syntactically valid in several grammars simultaneously:

It closes several possible enclosing contexts (</title>, </style>, </script>) and then injects an auto-firing element — so whichever context it landed in, one of the escapes works. For testing, a polyglot is a quick "is this injectable at all?" probe; for defenders, it's a vivid demonstration of why context-correct encoding (not pattern-matching) is the only reliable answer.

Beyond alert(1): What Real Payloads Do

alert(1) proves execution; real payloads (Chapter 5) replace it with meaningful actions, often loaded from a remote script to keep the injected string small:

Hands-On Exercises

Chapters 1–4 covered the mechanism; this one covers the impact — what an attacker actually does once their script runs same-origin. Understanding the breadth of damage is what justifies treating XSS as a critical bug rather than a cosmetic one. Every capability below follows from a single fact: the script has the full power of the page, in the victim's authenticated session.

1. Session/Cookie Theft

The classic impact: exfiltrate the session cookie so the attacker can impersonate the victim from their own machine — no password needed.

HttpOnly cookies (Chapter 10) defeat this specific read — but as Chapter 1 noted, the script can still act within the session directly, so cookie theft is just the most convenient option, not the only one.

2. Session Riding (Acting As the User)

Rather than steal the cookie, the script makes authenticated requests from the victim's own browser, where the session cookie is attached automatically — and, being same-origin, it can read the responses too. This works even against HttpOnly:

3. Credential Harvesting & Keylogging

Because the script controls the DOM, it can capture input directly or rewrite the page into a phishing trap that the user trusts (it's the real domain, real URL, valid certificate):

4. Data Theft

Same-origin reads mean the script can pull any data the user can see and exfiltrate it: page contents, personal info, messages, API responses, and non-HttpOnly tokens in localStorage (a reason bearer tokens in localStorage are risky, Chapter 9 / CSRF course Chapter 9).

Only one row is mitigated by HttpOnly — underscoring that HttpOnly is a useful layer but nowhere near a fix.

5. XSS Worms — Self-Propagation

The most dramatic impact: a stored XSS on a social platform can carry a payload that replicates itself. When a victim views the infected content, the script runs and uses session riding to post the same payload to the victim's own profile/content — which then infects everyone who views them, spreading exponentially.

6. Beyond the Page: BeEF-Style Control

Frameworks like BeEF (Browser Exploitation Framework) demonstrate XSS as a persistent foothold: the injected script "hooks" the browser and opens a control channel, letting an attacker pivot — fingerprint the browser, launch further attacks against the internal network the victim can reach, drive social-engineering popups, and maintain control as long as the page stays open. XSS becomes a beachhead, not just a one-shot.

Hands-On Exercises

Now the defences — and the first one is the most important. Output encoding (also called output escaping) is the primary, foundational defence against XSS: transform untrusted data, at the moment it's written into a page, so the browser treats it as inert data rather than executable code. Get this right and the vast majority of XSS simply cannot occur, because nothing attacker-supplied is ever interpreted.

The Principle: Encode on Output, for the Context

Two words carry the whole chapter. "On output": encode at the point data is inserted into the page, not when it's received. "For the context": use the encoder matching where the data lands (Chapter 3 — HTML, attribute, JS, URL, CSS). Encoding converts the characters that would break out of the current context into safe equivalents the browser displays literally.

The Five Encoders

The non-negotiable rule from Chapter 3 holds: the encoder must match the context. HTML-encoding a value that lands in a JavaScript string or a URL scheme does not protect it.

In Practice: Don't Hand-Roll It

You rarely write these encoders yourself — and shouldn't. Use established, context-aware tools:

• Template engines auto-encode by default — Handlebars {{value}}, EJS <%= value %>, Jinja/Twig, Razor. The raw forms ({{{value}}}, <%- %>) bypass it — those are the danger spots to audit.
• Frameworks auto-encode interpolated values — React {value}, Vue {{ }}, Angular — covered in Chapter 9.
• Libraries for manual cases — OWASP Java Encoder, the he library (Node), Python's markupsafe.

Encoding vs Sanitization — Not the Same Thing

A crucial distinction that the next chapter expands: encoding makes data display literally (good when the value should be shown as text — a username, a comment, a search term). Sanitization (Chapter 7) removes dangerous parts while keeping some markup functional (needed when the value is meant to be HTML — a rich-text comment). Use encoding by default; reach for sanitization only when you genuinely must render user-provided HTML.

Why Encoding Is the Foundation

Recall Chapter 4: blocklist filtering loses because the attacker has infinite payload variants. Output encoding wins for the mirror-image reason — it doesn't try to recognize bad input; it neutralizes a small, closed set of breakout characters for the current context, so every variant of every payload is rendered inert at once. It's complete by construction, not by enumeration. That's why it's the primary defence, with sanitization (Ch. 7) and CSP (Ch. 8) layered on top — defence in depth, but encoding is the load-bearing wall.

Hands-On Exercises

Output encoding (Chapter 6) handles the common case — data shown as text. But sometimes the value is meant to be HTML: a rich-text comment, a CMS article, a formatted message. You can't encode it (that would show the tags as text) and you can't trust it (it may contain a payload). The answer is HTML sanitization: parse the HTML and keep only a known-safe allowlist. This chapter also pins down where input validation genuinely helps — and where it's mistaken for an XSS defence.

When You Actually Need Sanitization

Sanitization is the exception, not the default. You need it only when all three are true: the input is user-provided, it must render as HTML (not text), and you therefore can't simply encode it. If any is false, prefer encoding (Chapter 6) — or avoid raw HTML entirely by accepting Markdown and rendering it through a safe renderer.

Allowlist, Never Blocklist

A sanitizer works by parsing the input into a DOM and keeping only explicitly permitted elements and attributes, dropping everything else. This is the positive model from Chapter 4 — define what's safe, discard the rest — the opposite of trying to strip "bad" tags:

The Tool: DOMPurify

Don't write an HTML sanitizer — sanitizing HTML correctly is brutally hard (browser parsing quirks, mutation, mXSS), and hand-rolled ones are reliably bypassed. The industry-standard library is DOMPurify:

Server-Side vs Client-Side Sanitization

DOMPurify runs in the browser and on the server (via jsdom). Where you sanitize depends on where the HTML is inserted:

• DOM-based / SPA — sanitize in the client right before innerHTML (the DOM-XSS fix from Chapter 2; encoding can't help there).
• Server-rendered — sanitize on the server before storing or emitting the HTML.
• Defence in depth — sanitizing on store and escaping/sanitizing on render is reasonable for high-risk HTML.

Where Input Validation Fits (and Where It Doesn't)

Input validation is good practice — but it is not the XSS defence, and treating it as one is a classic mistake.

The Decision Flow

1. Does the value need to render as HTML? If no → encode (Chapter 6). Done.
2. If yes → can you use Markdown/a structured format instead of raw HTML? If yes, prefer that (rendered safely).
3. If you must accept HTML → sanitize with DOMPurify, narrowest allowlist, kept updated.
4. Independently → validate structured fields for data quality, and layer CSP (Chapter 8) underneath everything.

Hands-On Exercises

Encoding (Chapter 6) and sanitization (Chapter 7) prevent injection. Content Security Policy is different in kind: it's a browser-enforced safety net that limits the damage if a payload does slip through. It's the classic defence-in-depth layer for XSS — not a substitute for encoding, but a powerful backstop that can turn a critical XSS into a non-event.

What CSP Does

CSP is an HTTP response header (Content-Security-Policy) that tells the browser which sources of content are allowed to load and execute. The browser enforces it. For XSS, the decisive power is controlling what scripts may run: even if an attacker injects <script> into the page, a good CSP means the browser refuses to execute it.

This says: load resources only from our own origin, run scripts only from our own origin (not inline, not from other domains), and block plugins entirely. An injected inline <script>alert(1)</script> violates script-src 'self' and is not executed.

Key Directives

Common source values: 'self' (same origin), 'none' (nothing), a domain allowlist, 'nonce-…', 'sha256-…', and the dangerous 'unsafe-inline' / 'unsafe-eval'.

The Hard Part: Inline Scripts

A strict script-src 'self' blocks all inline scripts — including the legitimate ones most sites have (<script>…</script> in the page, onclick= handlers). That's what makes CSP effective against XSS (injected scripts are inline), but it's also why adopting CSP is work. There are two safe ways to allow your inline scripts while still blocking injected ones: nonces and hashes.

The nonce is unpredictable and regenerated per response, so an attacker injecting a script can't know it and can't add a valid nonce= attribute — their script is blocked while yours runs. Hashes work similarly for static inline scripts: you put the script's SHA-256 in the policy ('sha256-…'), and only scripts matching that exact content execute.

Why CSP Is Defence-in-Depth, Not the Primary Fix

CSP must not be your only XSS defence, for several reasons: policies are easy to misconfigure (one 'unsafe-inline' and it's hollow); some XSS doesn't need to inject script tags (e.g. stealing data via allowed image/connect requests, or DOM-clobbering); older browsers have partial support; and a too-strict policy that breaks the site pressures teams to weaken it. Encoding and sanitization stop the injection; CSP limits the blast radius if they fail. Together they're strong; CSP alone is a leaky net.

A Strong Starting Policy

Modern guidance favours a nonce-based, "strict-dynamic" policy over long domain allowlists (which are easy to bypass via an allowlisted host's open redirect or a vulnerable script on it). Tools like Google's CSP Evaluator grade a policy and flag weaknesses like 'unsafe-inline' or overly broad allowlists.

Hands-On Exercises

Modern frameworks dramatically reduced XSS — not by magic, but by making output encoding the default so developers get it right without thinking. But every framework also provides escape hatches to render raw HTML, and those are where modern XSS lives. This chapter covers how the protection works, where it leaks, and the newest browser defence: Trusted Types.

Auto-Escaping: Safe by Default

React, Vue, and Angular all context-aware-encode interpolated values automatically. When you bind a variable into a template, the framework escapes it for you — the Chapter 6 discipline, built in:

This is why XSS rates fell as frameworks took over: the default path is safe, so the most common mistake (forgetting to encode) is eliminated for ordinary interpolation. The flip side — exactly like SameSite's "less, not gone" from the CSRF course — is that the escape hatches keep XSS alive.

The Escape Hatches — Where Modern XSS Lives

Each framework has an explicit "render this as raw HTML" API that bypasses auto-escaping. They're deliberately awkwardly named to signal danger:

It's Not Only innerHTML — Other Framework Sinks

Auto-escaping covers text interpolation, but some bindings remain dangerous because the value itself is a code-ish context (Chapter 3):

• URL bindings — a user-controlled href/src can be javascript:. React/Angular block some schemes, but binding untrusted URLs still needs scheme validation.
• Dynamic attribute/prop names and spreading untrusted objects into props can introduce handlers.
• Server-side rendering (SSR) + hydration can reintroduce injection if data is interpolated into the initial HTML or a <script> JSON island unsafely.
• Template injection — if untrusted data reaches the template compiler (e.g. server-side template engines, or eval-like dynamic templates), it's a far worse class than DOM XSS.

DOM XSS Hasn't Gone Away

Even in framework apps, plain DOM-XSS sinks (Chapter 2) bite when developers reach outside the framework: a stray element.innerHTML = userData, document.write, eval, setTimeout("string"), or assigning untrusted data to location. The framework only protects what flows through its templating; raw DOM manipulation is on you.

Trusted Types — Killing DOM XSS at the Sink

Trusted Types is a modern browser feature (enabled via CSP) that attacks DOM XSS structurally: it makes dangerous sinks (innerHTML, document.write, etc.) refuse plain strings — they only accept special typed objects produced by a policy you define and control.

Hands-On Exercises

The finale turns the course into practice: how to test for XSS, the broken-defence patterns to recognize in review, and a copy-pasteable hardening checklist that pulls all ten chapters together.

How to Test for XSS

1. Map every input → output flow — URL params, form fields, headers, stored data, and where each is reflected. Don't forget indirect reflections (a name set on one page, shown on another).
2. Inject a unique benign marker — e.g. xss7421 — and find where it lands in the response/DOM. This tells you the context (Chapter 3) before you craft a payload.
3. Try context-appropriate payloads — a tag in HTML body, a quote-breakout in an attribute, a scheme in a URL — or one polyglot probe (Chapter 4).
4. Check DOM XSS separately — trace client-side sources (location, hash) to sinks (innerHTML, eval); these won't show in server testing (Chapter 2).
5. Confirm execution safely — use console.log or a request to a collector you control, not noisy alert() (Chapter 4).

The Broken-Defence Catalogue

The Hardening Checklist

How the Course Fits Together

The arc: understand the bug (Ch. 1 — data vs code; same-origin power), the variants (Ch. 2 types, Ch. 3 contexts), the attack (Ch. 4 payloads, Ch. 5 impact), then the defences bottom-up — output encoding as the foundation (Ch. 6), sanitization for real HTML (Ch. 7), CSP as the backstop (Ch. 8), framework auto-escaping & Trusted Types (Ch. 9), and operational testing/hardening (Ch. 10). It also closes the loop with the CSRF course: XSS is the bug that defeats CSRF defences, which is why it's foundational and worth fixing first.

Hands-On Exercises