System Design Cases
CSRF & XSS Protection
CSRF and XSS protection: SameSite cookies, CSP nonce, output escaping, DOMPurify sanitization, Trusted Types, CORS misconfig leaks, SRI for compromised CDN. Eight scenarios covering stored XSS exploit, CSP-blocked injection, SameSite=Strict CSRF prevention, double-submit token pattern, base64+javascript: URI sanitizer bypass, CORS Allow-Origin reflection leak, and SRI hash mismatch. ADR on defense-in-depth security stack.
CSRF and XSS protection: separate browser threat boundaries
CSRF abuses browser-ambient authority to cause a cross-site state change; XSS executes attacker-controlled code in the trusted origin. Their prerequisites and primary controls differ, and same-origin XSS can defeat many CSRF defenses.
Security invariants
- WEB-C1: CSRF exploits ambient browser authority on state-changing requests; stateful applications use synchronizer tokens and stateless designs use signed session-bound double-submit tokens.
- WEB-C2: SameSite, host-only secure cookies, Origin or Referer, and Fetch Metadata are layered defenses; unsafe GET endpoints remain invalid.
- WEB-C3: XSS prevention uses context-specific encoding and safe sinks because HTML, attributes, URLs, CSS, and JavaScript have different parsers.
- WEB-C4: Intentionally supported rich HTML is sanitized with a maintained allowlist sanitizer and not modified afterward.
- WEB-C5: CSP and Trusted Types are defense-in-depth controls and do not replace safe rendering and sanitization.
- WEB-C6: Same-origin XSS can drive authenticated requests and bypass many CSRF mechanisms, while explicit bearer-header APIs have different ambient-credential prerequisites.
Trust-boundary map
| Component | Responsibility |
|---|---|
attacker-site | Attacker Site or Injected Script |
browser | Browser Security Model |
application | Web Application |
session-cookie | Protected Session Cookie |
session-state | Server-Side Session and CSRF State |
csrf-validator | CSRF and Request-Origin Validator |
renderer | Context-Aware Renderer |
html-sanitizer | Maintained HTML Sanitizer |
csp-trusted-types | CSP and Trusted Types |
api | State-Changing API |
sensitive-action | Sensitive Business Action |
security-log | Security Event Log |
Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.
Executable scenarios
synchronizer-token — Stateful synchronizer token
A stateful application issues an unpredictable session-bound token outside the cookie channel and verifies it on every unsafe request.
signed-double-submit — Signed session-bound double-submit token
A stateless design signs a value bound to session-specific data; a naive unsigned cookie comparison is vulnerable to cookie injection.
cross-site-csrf-rejection — Reject a cross-site forged request
A cross-site page can cause ambient cookies to be sent, but it cannot supply the session-bound token or an allowed origin under the policy.
samesite-defense-in-depth — SameSite and cookie prefixes are defense in depth
SameSite narrows cross-site cookie delivery, while host-only secure cookies and origin checks address sibling-domain and deployment mistakes; unsafe GET actions remain forbidden.
contextual-xss-output — Contextual output handling and safe sinks
Untrusted text is encoded for its exact HTML, attribute, URL, CSS, or JavaScript context, with dangerous contexts avoided and DOM text sinks preferred.
sanitized-rich-html — Sanitize intentionally supported rich HTML
When HTML authoring is required, a maintained allowlist sanitizer produces the final value and no later mutation reintroduces unsafe markup.
csp-trusted-types-layer — CSP and Trusted Types limit impact
A nonce or hash based CSP and Trusted Types constrain script execution and dangerous DOM sinks but remain defense in depth behind safe rendering.
xss-defeats-csrf — Same-origin XSS can defeat CSRF controls
Code executing in the trusted origin can read non-HttpOnly CSRF material or drive same-origin requests that include protected cookies and custom headers.
bearer-header-boundary — Non-ambient bearer APIs have a different CSRF boundary
A token sent only in an explicit Authorization header is not automatically attached by a cross-site form, but CORS, token theft, and XSS remain separate threats.
Operational and failure rules
- Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
- Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
- Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
- Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.