Defense in Depth

Each CSRF defence has a specific gap, and the gaps do not overlap. That is the argument for layering — not vague caution, but the observation that the thing which defeats one layer is precisely what the next layer catches.

• SameSite fails against a same-site attacker, against state-changing GET, and against non-cookie credentials.
• A token fails against XSS and against a CORS misconfiguration that lets the attacker read it.
• Header checks fail when the header is absent, when a proxy rewrites it, and against a same-site attacker.
• Content-type enforcement fails to a single misconfigured body parser.

Stack them and each layer covers another's gap. The recommended order below is by cost-to-benefit: the first two are configuration changes, the third is a dozen lines of middleware, and only the fourth requires real work.

Three things stand out, and they are the practical takeaways:

Re-authentication is the only column with no gaps except XSS. That is why it belongs on the operations that actually matter — password change, email change, adding a payment method, adding an API key, granting an OAuth scope, deleting an account. It is not a general CSRF defence because it cannot be applied to every request, but for the handful of actions that grant durable control it is the strongest thing available.

XSS defeats everything. Script running on the target's own origin reads the token, satisfies every header check, and is same-origin by definition. There is no CSRF control that survives it, which is why a CSRF finding on a page with XSS is redundant and why XSS should always be fixed first.

SameSite alone leaves three holes — GET, same-site attackers, and non-cookie credentials — and all three are common. Teams that adopted SameSite=Lax and removed their tokens made themselves less safe, not more.

Re-authentication has a real usability cost, so apply it where the action grants durable control rather than everywhere. The test: if an attacker performed this once, would they retain access afterwards?

Yes, so require it:

• Changing the email address or the recovery phone number
• Changing the password
• Adding or changing a payment method or payout destination
• Creating an API key, personal access token, or SSH key
• Linking a new identity provider or OAuth application
• Adding a user to a team, or granting admin
• Disabling MFA, or adding an MFA device
• Deleting the account or exporting all data

No, a token is enough:

• Ordinary content edits, preferences, and settings
• Anything reversible and visible to the user

And pair the high-value list with out-of-band notification — an email to the previous address on an email change, with an undo link. That does not prevent the action, but it bounds the damage and is frequently the only control that catches a successful attack after the fact.

Cookies

• SameSite=Lax set explicitly on the session cookie
• __Host- prefix, Secure, HttpOnly, no Domain
• HSTS with includeSubDomains, preloaded
• Session identifier regenerated on login and privilege change

Headers

• Sec-Fetch-Site rejection for cross-site state changes, mounted globally
• Missing-header behaviour decided deliberately and documented
• Origin exact-matched against an allowlist where used; null never allowlisted
• Content-Security-Policy: frame-ancestors 'none'

Token

• Default-deny middleware, empty exemption list
• Bound to the session, rejected when absent, constant-time comparison
• Per-session, rotated on login
• Never in a URL

Requests

• GET, HEAD, OPTIONS are side-effect free
• Content type enforced with a 415 on state-changing routes
• Explicit verbs on every route; method override from a header only, applied before the CSRF check

High-value operations

• Re-authentication required
• Out-of-band notification sent, with an undo path

Subdomains

• Enumerated, and dangling DNS records audited on a schedule
• same-site treated as untrusted if any subdomain hosts user content