Cheatsheet

The behavioural source of truth for this site. Every cell below is checked against the PoC generator at build time — if the table and the generator ever disagree about a verdict, the build fails.

Does the cookie ride along?

Rows are how an attacker's page makes the request. Columns are the target's session cookie policy. Depends means the engines disagree — read the note, and name the browser in your finding.

Request made from a cross-site page	SameSite=None; Secure	SameSite=Lax	SameSite=Strict	No SameSite attribute
Top-level GET navigation — location =, window.open, scripted <a>.click()	Sent	Sent	Blocked Strict is never sent on a cross-site request, including a navigation the user initiated.	Sent
<form method="GET"> submitted top-level	Sent	Sent	Blocked	Sent
<form method="POST"> submitted top-level	Sent A top-level navigation makes the target the first party, so no third-party cookie policy applies.	Blocked Lax needs a top-level navigation AND a safe method. POST is not safe.	Blocked	Depends Chromium blocks it via the Lax default, except within the 120-second Lax+POST window for a freshly-set cookie. Firefox and Safari never shipped a Lax default and send it unconditionally. This is the single most misreported cell in CSRF findings.
<form method="POST" target="hidden-iframe">	Depends Chromium sends it; Firefox partitions it under Total Cookie Protection; Safari blocks third-party cookies outright.	Blocked	Blocked	Blocked Submitting into a frame is a subresource request, not a navigation — so it loses the one shape that still carries an unset cookie.
<img>, <script>, <link rel=stylesheet>, CSS url()	Depends Chromium sends it; Firefox partitions it; Safari blocks it.	Blocked	Blocked	Blocked Dead in all three engines, for three different reasons: Chromium's Lax default, Firefox's Total Cookie Protection, Safari's third-party blocking.
<iframe src="…">	Depends Chromium sends it; Firefox partitions it; Safari blocks it. This is why a framed target renders logged out — and why clickjacking-assisted CSRF now needs SameSite=None or a popup.	Blocked	Blocked	Blocked
fetch(url) — default credentials	Blocked fetch defaults credentials to 'same-origin', so no cookie is attached at any SameSite value. Same for XHR without withCredentials.	Blocked	Blocked	Blocked
fetch(url, {mode:'no-cors', credentials:'include'})	Depends Chromium sends it; Firefox partitions it; Safari blocks it.	Blocked	Blocked	Blocked
XMLHttpRequest with withCredentials = true	Depends Identical cookie behaviour to fetch. The differences are the preflight for non-simple shapes and an unreadable response without Access-Control-Allow-Origin.	Blocked	Blocked	Blocked
navigator.sendBeacon(url, blob)	Depends Credentials mode is 'include' by spec, but it is still a subresource, so Lax and Strict block it regardless.	Blocked	Blocked	Blocked
new WebSocket('wss://target/…') handshake	Depends The handshake is a subresource GET with no CORS, so cross-site WebSocket hijacking requires SameSite=None. Chromium sends it; Firefox partitions it; Safari blocks it.	Blocked	Blocked	Blocked
Any request initiated from the target's own origin (on-site open redirect, client-side redirect gadget)	Sent	Sent	Sent Not cross-site, so SameSite does not engage at all. This is exactly how an on-site gadget defeats SameSite=Strict.	Sent

What this table does not cover

HTTP Basic, Digest, NTLM/Negotiate, and TLS client certificates are ambient but are not cookies, so no cookie attribute governs them. Every row reads “sent”. See Routers, IoT, and localhost.
Authorization: Bearer is never ambient — the browser does not attach it. Token-in-header APIs are not CSRF-able by anything on this page.
A Partitioned (CHIPS) cookie lives in a jar keyed to the top-level site, so the attacker's page gets an empty partition and every third-party row reads “blocked”.
Schemeful same-site: http://target and https://target are cross-site to each other. Match the scheme in your PoC.
Chromium columns assume a default profile. Incognito blocks third-party cookies, and so do many users' settings and extensions.
A same-site attacker — anything on a sibling subdomain — is not cross-site at all, so none of these restrictions apply to them. See Subdomain Cookie Injection.

What each framework does by default

Column headers link to the full prevention guide.

	Django 5.x	Rails 8	Spring Security 6	Laravel 11/12	ASP.NET Core 9	Express 5 / Node	Go (net/http)
On by default	Yes — CsrfViewMiddleware is in the default MIDDLEWARE list	Yes — default_protect_from_forgery since 5.2	Yes — CsrfFilter is on unless you disable it	Yes — for the web middleware group	Razor Pages and MVC views yes; Web API controllers no	No — nothing is built in	No, but net/http ships CrossOriginProtection since Go 1.25
Pattern	Masked double-submit; synchronizer with CSRF_USE_SESSIONS	Synchronizer, session-stored, XOR-masked	Synchronizer (HttpSessionCsrfTokenRepository)	Synchronizer plus an XSRF-TOKEN mirror cookie	Encrypted token pair, bound to the authenticated user	Whatever you install	Fetch metadata (Sec-Fetch-Site), or gorilla/csrf for tokens
Token storage	csrftoken cookie, or the session	Session	Session, or an XSRF-TOKEN cookie	Session plus an encrypted cookie	.AspNetCore.Antiforgery.* cookie	—	— (header-based), or a cookie with gorilla/csrf
Form helper	{% csrf_token %}	form_with and csrf_meta_tags	Thymeleaf injects _csrf automatically	@csrf	The form tag helper injects it automatically	—	csrf.TemplateField
AJAX header	X-CSRFToken	X-CSRF-Token	X-CSRF-TOKEN or X-XSRF-TOKEN	X-CSRF-TOKEN or X-XSRF-TOKEN	Configurable via options.HeaderName	Convention only	X-CSRF-Token
Origin / Referer check	Yes — Origin against CSRF_TRUSTED_ORIGINS since 4.0, Referer fallback on HTTPS	Yes — forgery_protection_origin_check	No	No	No	No	Yes — Sec-Fetch-Site with an Origin fallback
Methods treated as safe	GET HEAD OPTIONS TRACE	GET HEAD	GET HEAD TRACE OPTIONS	GET HEAD OPTIONS	GET HEAD OPTIONS TRACE	—	GET HEAD OPTIONS
Session cookie SameSite default	Lax (SESSION_COOKIE_SAMESITE)	Lax since 5.2	Unset — server.servlet.session.cookie.same-site has no default	lax (config/session.php)	Lax on the auth cookie; the antiforgery cookie itself is Strict	Unset — express-session sets nothing	Unset — you set it yourself
Escape hatch	@csrf_exempt	skip_forgery_protection, or with: :null_session	.csrf(c -> c.ignoringRequestMatchers(...)) or .disable()	validateCsrfTokens(except: [...])	[IgnoreAntiforgeryToken]	—	AddTrustedOrigin, or simply not wrapping the mux
Biggest footgun	@csrf_exempt on API views; DRF SessionAuthentication is checked but TokenAuthentication skips CSRF entirely	with: :null_session on a controller that still uses cookie sessions — the request proceeds with an empty session instead of failing	.csrf().disable() copied from a stateless-JWT tutorial into a cookie-session app; withHttpOnlyFalse() degrades it to plain double-submit	Wildcards in the except list; Sanctum SPA mode with a wrong SANCTUM_STATEFUL_DOMAINS	[ApiController] plus cookie auth means no antiforgery runs at all	csurf was deprecated and archived in 2022; express.json({type:'/'}) reopens the text/plain vector	Forgetting to wrap the mux; gorilla/csrf without TrustedOrigins behind a proxy
Recommended 2026 baseline	Keep the defaults, add a __Host- prefix and SameSite=Lax	Keep the defaults	CookieCsrfTokenRepository + XorCsrfTokenRequestAttributeHandler, plus your own Origin check	Keep the defaults and keep except empty	[AutoValidateAntiforgeryToken] globally, including API controllers	csrf-csrf (signed double-submit) plus a Sec-Fetch-Site rejection	http.NewCrossOriginProtection() wrapping the mux