DOM XSS Taint Flow 2D: Parallel Sink Lanes & Defense Matrix

Defense Layers

Output Encoding

HTML-encodes markup chars

DOMPurify / Allowlist

Strips tags, on* attrs, js: URLs

Strict CSP

No unsafe-inline / unsafe-eval

Total attack rate 10/s

Aggregate Outcome

Attempts

Blocked

Executed (XSS)

Success rate

0.0%

How it works

Every sink runs as its own lane, all five in parallel, all evaluated against the same live defense state. Each particle is judged the instant it launches, at the first gate that applies to its lane's sink:

execute(sink) = payload reaches sink
              AND ¬blocked_by(Encoding, sink)
              AND ¬blocked_by(Purify, sink)
              AND ¬blocked_by(CSP, sink)

The matrix panel above the lanes renders this rule as a live truth table — a defense only helps if it matches the sink's execution context, which is the real cause of most "we sanitized it and got popped anyway" incidents:

Output Encoding escapes HTML metacharacters so markup becomes inert text — it does nothing to eval() input or a javascript: URL, because neither is HTML.
DOMPurify / allowlist parses the fragment as HTML and strips disallowed tags, event handlers and dangerous URL schemes — it never sees data passed straight to eval().
Strict CSP makes the browser refuse inline handlers and eval regardless of app code — but it does not stop a user clicking a malicious javascript: link.

Running all five sinks side by side (rather than one at a time) makes the asymmetry visible directly: the same three toggles produce five different outcomes simultaneously.

In flight Blocked (encoding) Blocked (DOMPurify) Blocked (CSP) Executed (XSS fired)