CSRF in the SameSite era: why the default helped but didn''''t kill it

A bank ships a “transfer funds” endpoint and feels safe — sessions are cookie-based, HTTPS everywhere, login is solid. Months later a user clicks a link in a forum post. The linked page silently auto-submits a hidden form to POST /transfer with amount=5000&to=attacker. The browser does what browsers do: it attaches the user’s session cookie to the cross-site request. The server sees a valid, authenticated session and moves the money. No password was stolen, no session was hijacked. The attacker never saw the response — they didn’t need to. The side effect already happened.

The mechanism: ambient authority

CSRF exists because of one browser behavior: cookies are ambient authority. The browser attaches a site’s cookies to every request to that site’s origin — no matter who initiated the request. A form on evil.com that posts to bank.com still gets the bank’s session cookie attached, because the browser keys cookies by destination, not by who started the navigation. The attacker doesn’t need to read the cookie or steal it (HttpOnly stops that, and is irrelevant here). They only need to make the victim’s browser send a request. The authentication comes along for free.

That’s the whole trick, and it’s why CSRF is sometimes called “the confused deputy”: the browser is a deputy acting with the user’s authority, confused into using that authority on the attacker’s behalf. Crucially, the attacker cannot read the response — the same-origin policy blocks that. CSRF is a write attack, not a read attack. It works on any endpoint where the side effect alone is the goal: transfer money, change email, delete account, promote a user to admin.

SameSite=Lax: the 2020 default that changed everything

In February 2020, Chrome 80 made SameSite=Lax the default for any cookie that doesn’t specify the attribute. Firefox and Edge followed. This was the single biggest blow to classic CSRF in the web’s history. A Lax cookie is not sent on cross-site subrequests — the evil.com form posting to bank.com no longer gets the cookie attached, so the attack above is dead by default for a POST.

But “Lax” is not “Strict,” and the gap is deliberate. Lax does send the cookie on top-level navigations using safe methods — when the user clicks a link and the URL bar changes to your site, the cookie comes along (otherwise every inbound link would log you out). Two consequences follow directly, and both are live CSRF vectors.

Why CSRF is not dead

GET-based state changes. If GET /account/delete or GET /transfer?to=x&amount=5000 actually mutates data, Lax happily sends the cookie on a top-level navigation. An attacker just needs the victim to click a link (or land on a page that redirects). This is why “never mutate on GET” is a real security rule, not a REST style preference.

SameSite=None. Any site that legitimately needs cross-site cookies — embedded widgets, third-party SSO, an API consumed from another origin — must set SameSite=None; Secure, which turns all SameSite protection off for that cookie. The moment you opt into cross-site, you’re back to pre-2020 and need a real token defense.

The Lax+POST window. Chrome’s default-Lax (not explicit SameSite=Lax) keeps a compatibility exception: a brand-new cookie is sent on a top-level cross-site POST for the first 120 seconds, to avoid breaking some SSO redirects. That’s a ~2-minute CSRF window right after the cookie is set. Setting SameSite=Lax explicitly removes this exception.

Inconsistent enforcement. Default-Lax is enforced by the browser. Older browsers, embedded WebViews, and some non-Chromium clients don’t all behave identically, and you cannot assume the server is protected by a client-side default. SameSite is a defense-in-depth layer, never the only lock.

The defenses that still matter

SameSite shrinks the surface; it does not replace a token defense for any endpoint that matters. Two server-side patterns remain the backbone:

• Synchronizer token pattern. The server generates a per-session (or per-request) cryptographically random token, stores it server-side, and embeds it in every form / sends it in a custom header. The attacker’s cross-site page can’t read it (same-origin policy) and can’t guess it. The server rejects any state-changing request whose token doesn’t match. Stateful, strongest, the OWASP default for server-rendered apps.
• Double-submit cookie. Stateless: the server sets a random value in a cookie and expects the same value echoed in a header / form field. The attacker can’t read your cookie to copy it into the header, so the two won’t match. Cheaper (no server storage) but weaker — vulnerable if an attacker can write cookies for your domain (e.g. a subdomain XSS), which is why OWASP now recommends the HMAC signed variant that binds the token to the session.

Add a defense-in-depth layer on sensitive endpoints: verify the Origin header (and fall back to Referer) matches your own origin, rejecting requests from foreign origins. And for JSON APIs, requiring a custom header (e.g. X-Requested-With) plus a non-simple content type forces a CORS preflight — which the attacker’s cross-site fetch cannot satisfy without your CORS policy allowing it. That’s a partial mitigation, not a full token defense, because top-level form posts and some content types skip preflight.