DOM-based vulnerabilities

What makes DOM-based different from every other vulnerability in the catalogue: the server never sees the payload, so every server-side defence is blind to it.

• The WAF does not see it. location.hash (the part after the #) is not sent to the server — the browser keeps it. A payload in the fragment passes every WAF, every log, every server-side check.
• Server-side tests cannot catch it. No request contains the payload for an integration test to see. It needs a real browser to reproduce.
• The framework does not handle all of it. React escapes the HTML body, but dangerouslySetInnerHTML, location = userUrl, and eval are still dangerous sinks the framework does not block.

This is a form of XSS (see the xss topic), but different enough to stand alone: reflected/stored XSS passes through the server and can be fixed there; DOM-based can only be fixed client-side, and you find it by tracing source → sink in JavaScript, not by scanning requests.

The mechanism is a source → sink flow entirely in the browser. Knowing the source list and the sink list is how you hunt it systematically.

flowchart LR    subgraph SRC["Sources (attacker-controlled)"]        S1["location.hash / .search"]        S2["postMessage"]        S3["localStorage / document.referrer"]    end    subgraph SINK["Sinks (execution)"]        K1["innerHTML / outerHTML"]        K2["eval / Function / setTimeout(str)"]        K3["location / location.href"]    end    S1 --> K1 & K2 & K3    S2 --> K1    S3 --> K1    K1 --> X["XSS — script runs in the origin"]    K2 --> X    K3 --> O["Open redirect / javascript: URL"]

The key point: the server is not in the diagram. The whole source-to-sink flow happens in JavaScript on the victim's machine, so it is a client-code bug, findable only by reading the client code or using a real browser.

A source-and-sink table — the map for hunting:

postMessage deserves its own note: a message handler that does not check event.origin accepts data from ANY page that can open a frame to yours — so an attacker page frames yours and posts a payload. This is a common DOM XSS that few people hunt for.

A "share" widget reads the page title from the fragment to show a heading — and the fragment never reaches the server.

// ❌ Source: location.hash. Sink: innerHTML. The server sees NOTHING.// URL: https://app.example/share#<img src=x onerror=fetch('/api/keys')>const title = decodeURIComponent(location.hash.slice(1));document.getElementById("preview").innerHTML = "Sharing: " + title;

The payload is after the #, so it exists only in the browser. The WAF, server logs and server-side integration tests all miss it — only a real browser (or reading the code) finds it.

// ❌ postMessage with no origin check. ANY page framing this one can post.window.addEventListener("message", (e) => {  // Missing e.origin check → accepts data from any frame.  document.getElementById("chat").innerHTML += e.data;});

// ❌ Source → location. Open redirect and javascript: URL.// URL: https://app.example/go#javascript:fetch('/api/keys')location = location.hash.slice(1);   // runs javascript: or navigates to the attacker's site

// After the fix: textContent instead of innerHTML, check the origin, check the scheme.preview.textContent = "Sharing: " + title;             // does not parse HTMLif (e.origin !== "https://app.example") return;         // only accept from our own origin

DOM XSS in advertising and analytics libraries (many reports). Many third-party scripts read location and write to innerHTML to "personalise", and they run on millions of pages. Memorable because the vulnerability is in code you did NOT write but embedded — and it is invisible to all your server-side checks.

The postMessage family (Facebook, many SDKs, 2013–present). Embedded SDKs (login buttons, chat widgets) use postMessage to communicate between an iframe and the parent, and handlers missing an origin check accept data from the attacker's page. This is the source of the postMessage concept in block 3, and it still appears regularly.

DOM Invader (PortSwigger) and DOM Clobbering research. The tooling and research show the real scale of DOM XSS: it is more common than reflected XSS on JavaScript-heavy applications, precisely because nobody hunts it — a server-side scanner does not see it, and it needs source-to-sink flow analysis of the client code.

1. Grep the dangerous SINKS in the client code — the cheapest check, and the sink list is finite:

grep -rnE '\.innerHTML|\.outerHTML|\beval\(|new Function\(|setTimeout\([^,]*[a-z]' \  --include='*.ts' --include='*.tsx' --include='*.js' --include='*.vue' src/ \  | grep -v 'textContent\|DOMPurify\|sanitize' \  && { echo "dangerous DOM sink — review its source"; exit 1; }exit 0

2. Grep postMessage handlers with no origin check:

grep -rnE 'addEventListener\(\s*["\x27]message["\x27]' -A6 \  --include='*.ts' --include='*.tsx' --include='*.js' src/ \  | grep -L 'e\.origin\|event\.origin' \  && echo "a message handler may be missing an origin check"# And grep postMessage(data, "*") — sends to any origin.grep -rnE 'postMessage\([^,]+,\s*["\x27]\*["\x27]' --include='*.ts' --include='*.tsx' src/ \  && { echo "postMessage targetOrigin=* — sends to any page"; exit 1; }exit 0

3. Static source-to-sink flow analysis — grep sees the sink; flow analysis sees the DATA reaching the sink from an untrusted source. Run the CodeQL query js/dom-xss in CI. This is the only check that finds it systematically.

4. Test in a REAL BROWSER — the only check that reproduces it, because a fragment payload does not reach the server:

// Playwright. A payload in the hash → assert it does NOT run.test("the hash does not become XSS", async ({ page }) => {  await page.goto(`${BASE}/share#<img src=x onerror=window.__pwned=1>`);  expect(await page.evaluate(() => window.__pwned)).toBeUndefined();  // And the string appears as TEXT, which is correct.  expect(await page.textContent("#preview")).toContain("<img");});

5. Check Trusted Types is on (layer 2):

curl -sI https://app.example/ | grep -i content-security-policy \  | grep -q "require-trusted-types-for" || echo "WARNING: Trusted Types missing"

The location mistake, and it is the central one: hunting and fixing on the server. DOM XSS is a wholly client-side bug — the source, the sink and the execution are all in the browser. You find it by tracing source → sink in JavaScript, not by scanning requests.

The tooling mistake: using a server-side scanner. They send a request and inspect the response — but a DOM XSS payload lives in a fragment that never reaches the server, so the scanner sees a clean page. You need client-side flow analysis (CodeQL) or a real-browser test (DOM Invader, Playwright).