XSS and Content Security Policy

A gate-crasher slips a note to the staff. If the announcer reads it aloud as a quotation, it is only words. If a footman hands it to the band as tonight's running order, the band obeys it. The doorman lets a guest onto the floor only if they wear tonight's freshly cut wristband — never because a name sits on a standing-invitation list, which anyone can forge.

At the ball	In the browser
a note read aloud as a quotation	data encoded for its context: inert (steps 5–6)
a note handed to the band as the running order, and obeyed	data reaching a sink and running as code (steps 1, 5)
a note slipped back to the sender / pinned to the board / picked up by the band itself	reflected / stored / DOM delivery (steps 2–4)
tonight's freshly cut numbered wristband	a per-response CSP nonce (step 9)
a standing-invitation list anyone can forge	a host allow-list, bypassable (step 9)
the bandmaster refusing any note not copied onto an official card	Trusted Types guarding DOM sinks (step 9)

In real terms: the same author string is safe as a quotation and dangerous as an instruction; which one it becomes is decided entirely by where your code puts it.

Breaks down when: "we sanitized the input, so we are safe." Encoding must match the output context, and a fragment-read value never reaches the server's input filter at all (step 4).

Contrasting case: the same-origin policy and CORS (the prereq) govern reading other origins' responses. XSS runs inside your own origin, where those rules never apply.

Every marker below fired, or stayed inert, in Playwright's Chromium against a local vulnerable page. window.__xss = 1 is the whole payload.

4.1 EXH-1400: the author marker reaching the candidate page three ways

One question author's stored rich-text body (an <img onerror> marker) ran inside every candidate's exam page. The same marker is shown arriving reflected, stored and via the DOM, then stopped by encoding for the output context (MR !1600).

vulnerable:
  reflected (server echoes ?q)     marker FIRED
  stored (served author body)      marker FIRED
  DOM (client innerHTML of hash)   marker FIRED
after the fix — MR !1600 (encode for the HTML context on OUTPUT; safe DOM sink):
  reflected + server escapeHtml    marker inert | shows literal: for <img src="does-not-exist" 
  stored + server escapeHtml       marker inert | shows literal: <img src="does-not-exist" oner
  DOM + textContent sink           marker inert | shows literal: <img src="does-not-exist" oner

The reflected and stored holes are closed by HTML-escaping on output (steps 2–3, 5–6). The DOM hole is not: the value never reaches the server, so the fix is a safe client sink — textContent instead of innerHTML (step 4).

4.2 React escaping and its escape hatches

Observed from the pinned react-dom/server, then mounted in Chromium. React escapes a text child and an attribute; the escape hatches pass raw HTML through; React 19 rewrites a javascript: URL to a throw.

React 19.3.0 — renderToStaticMarkup output (observed):
  text child {author}      -> <div>&lt;img src=&quot;does-not-exist&quot; onerror=&quot;window.__xss=1&quot;&gt;</div>
  attribute title={author} -> <div title="&lt;img src=&quot;does-not-exist&quot; onerror=&quot;window.__xss=1&quot;&gt;">hi</div>
  dangerouslySetInnerHTML  -> <div><img src="does-not-exist" onerror="window.__xss=1"></div>
  <a href={javascript:...}> -> <a href="javascript:throw new Error(&#x27;React has blocked a javascript: URL as a security precaution.&#x27;)">continue</a>
mounted in Chromium:
  escaped text child               marker inert | inert text, no element
  dangerouslySetInnerHTML          marker FIRED | raw HTML → sink runs
  javascript: href, clicked        marker inert | URL scheme is a sink

Text and attribute values are escaped, so {userData} is inert (step 7). dangerouslySetInnerHTML is the real hole — raw HTML reaches the sink and runs (step 8). React 19 additionally blocks javascript: URLs in href, so that one hatch is closed in React; the raw DOM has no such guard (step 7).

4.3 CSP: the same injected marker under each policy

The identical injected marker is served into the page under six policies; Chromium enforces each. A per-response nonce blocks it; a host allow-list that trusts a reflecting host does not.

1. no CSP                              marker FIRED
2. host allow-list incl. the CDN       marker FIRED   (allow-listing a reflecting host is bypassable)
3. per-response nonce vs CDN script    marker inert | violation script-src-elem:http://127.0.0.1:PORT/jsonp?cb=window.__xss%3D1
3b. per-response nonce vs inline handler marker inert | violation script-src-attr:inline
4. 'strict-dynamic': injected CDN script marker inert | violation script-src-elem:http://127.0.0.1:PORT/jsonp?cb=window.__xss%3D1 | app's own dynamic chunk ran: yes
5. Trusted Types (require-trusted-types-for) marker inert | violation require-trusted-types-for:trusted-types-sink | trustedTypes supported: object
6. hash-source (static inline app script) marker inert | app inline script ran: yes | 'unsafe-inline' ignored beside a hash

A host allow-list is not a boundary: the allowed host reflected the cb param into runnable JS (row 2). A per-response nonce blocks both an injected script (script-src-elem) and an injected inline handler (script-src-attr), reporting each (rows 3, 3b). strict-dynamic lets the app's own nonced code load a chunk while the injected script stays blocked, and host allow-list entries are ignored (row 4). Trusted Types refuses the DOM sink itself, reporting require-trusted-types-for (row 5). For a static or cached page with no per-response nonce, a script's hash allow-lists that inline script while the injected handler is blocked; 'unsafe-inline' beside a hash is ignored (row 6). CSP does not fix the injection; it limits what an injected script can do (step 9).