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.

▶Walkthrough: synchronizer-token (not found)

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.

▶Walkthrough: signed-double-submit (not found)

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.

▶Walkthrough: cross-site-csrf-rejection (not found)

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.

▶Walkthrough: samesite-defense-in-depth (not found)

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.

▶Walkthrough: contextual-xss-output (not found)

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.

▶Walkthrough: sanitized-rich-html (not found)

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.

▶Walkthrough: csp-trusted-types-layer (not found)

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.

▶Walkthrough: xss-defeats-csrf (not found)

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.

▶Walkthrough: bearer-header-boundary (not found)

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.

Related concepts

[CONCEPT]owasp-top-10 [CONCEPT]api-security [CONCEPT]oauth-oidc [CONCEPT]authn-models

Authoritative sources

1. OWASP Cross-Site Request Forgery Prevention Cheat Sheet
2. OWASP Cross Site Scripting Prevention Cheat Sheet
3. OWASP Content Security Policy Cheat Sheet
4. W3C Content Security Policy Level 3