dom-based

DOM-Based Vulnerability Detection

Overview

A DOM-based vulnerability is an unsafe taint flow inside the browser: the site's own JavaScript reads an attacker-influenceable value (a source) and passes it into an API or DOM property (a sink) without validating, encoding or type-checking it. The server may return entirely benign markup — the flaw lives in the client bundle, which means it is invisible to server-side review and often invisible to logs. The attacker is remote: they hand the victim a crafted URL whose query string, fragment or path carries the payload, frame the page and drive it with a cross-document message, or plant a value in storage or a cookie that the page reads back later. What they gain depends entirely on which sink is reached — a credible phishing redirect from the real domain, a planted session cookie, a socket to their own server carrying the victim's data, a subverted client-side query, or a hijacked global variable that turns benign code into an attack primitive. This skill locates every source-to-sink flow in client code, checks each flow in parallel, and merges results into <output_dir>/dom-based-results.md.

What it is NOT

• Cross-site scripting (/websec:xss): the boundary is the sink, not the source. If the sink renders HTML or executes code — innerHTML, outerHTML, insertAdjacentHTML, document.write, srcdoc, eval, new Function, string-argument timers, createContextualFragment, jQuery .html()/$(…)/.append(), framework HTML bypasses — it belongs to /websec:xss, including the DOM-based, reflected-DOM and stored-DOM cases. Every other client-side sink family — navigation, document.cookie, storage, request headers, WebSocket(), JSON.parse, document.evaluate, executeSql, document.domain, FileReader, plain DOM properties, RegExp() — belongs here. When a flow in this skill escalates into a script-executing sink (an open redirect reached with a script pseudo-protocol, a storage write read back into innerHTML), record the escalation as impact here and note the executing sink for /websec:xss.
• Prototype pollution (/websec:prototype-pollution): polluting Object.prototype so unrelated code picks up an attacker property is a different mechanism. DOM clobbering — overriding globals by injecting named HTML elements — stays here. Both are gadget techniques; keep them apart in reporting.
• Server-side open redirection (/websec:open-redirect): a Location header built from a request value is a server bug fixed in the handler, and post-login return flows, allowlist bypasses and protocol-relative or scheme targets go with it. Test: does the browser leave because the server answered with a redirect, or because page JavaScript assigned a navigation property? Only the second belongs here.
• WebSocket protocol and authorisation flaws (/websec:websockets): message authorisation, cross-site socket hijacking and server-side message handling live there; only the client-side construction of the socket URL from a source belongs here.
• Server-side injection namesakes (/websec:sql-injection, /websec:xxe): client-side SQL, XPath and JSON injection run against an in-browser database or parser and cannot reach the backend by themselves; scope and impact are client-side only.
• Cross-origin read misconfiguration (/websec:cors): a permissive response header is a server-side trust decision, not a taint flow. A message listener with no origin check is this skill.
• Not a finding: a write to a cookie or storage key whose value is never read back into anything security-relevant; a source that reaches a sink through an exact allowlist or a relative-path-only constraint; a message listener that compares event.origin for equality against a fixed origin before using the data; a value that is developer-controlled by the time it reaches the sink (a constant, an enum lookup, an index into a fixed table); DOM writes of values the same user already controls in their own page with no cross-user or cross-origin effect.