CSRF, SameSite cookies and where the session lives

Cross-site request forgery needs no bug in your HTML and no script on your page. It uses one browser behaviour: cookies are attached to requests by destination, not by who started the request. (How cookie sessions and bearer tokens work as mechanisms is the Auth over HTTP unit; this one is about the attack.)

You're logged in to bank.example, so your browser holds its session cookie. You then visit a page on evil.example that contains:

<form action="https://bank.example/transfer" method="POST">
  <input type="hidden" name="to" value="attacker" />
  <input type="hidden" name="amount" value="5000" />
</form>
<script>document.forms[0].submit();</script>

The form posts to the bank. Unless the cookie's SameSite setting stops it (next reading), the browser attaches your bank session cookie, the bank sees an authenticated request from you, and the transfer goes through.

Three facts define the attack:

• The attacker can make the request but can't read the response. CSRF is write-only: it changes state (transfer, change email, delete) and gains nothing from what comes back.
• It needs credentials the browser adds on its own — cookies (or HTTP auth). An API that authenticates with an Authorization: Bearer … header that your JavaScript adds isn't exposed this way: evil.example can't make the browser add that header.
• It needs a request the attacker can predict. A POST /transfer with to and amount is fully predictable; a request that must carry a secret the attacker can't know (a CSRF token) is not.

And one rule everything else builds on — OWASP: "Do not use GET requests for state changing operations." A link, an image tag or a redirect can all trigger a GET. If GET /logout or GET /posts/42/delete changes state, an <img src> on any site is enough.

The server can ask the browser where a request came from, because modern browsers say so in headers that page script cannot set or change.

Sec-Fetch-Site (Fetch Metadata; in every major browser since March 2023, per MDN) describes the relationship between the page that started the request and your server:

Origin carries the initiating page's scheme, host and port (never the path). Browsers send it on cross-origin requests and on same-origin requests other than GET/HEAD (MDN), so it's present on the state-changing requests you care about. Sandboxed frames, data: documents and a few other cases send the literal string null.

OWASP's guidance turns these into a guard for non-safe methods (POST, PUT, PATCH, DELETE):

const SAFE = new Set(["GET", "HEAD", "OPTIONS"]);
const TRUSTED = new Set(["https://app.example.com"]);

function isAllowed(method: string, headers: Headers): boolean {
  if (SAFE.has(method)) return true;                  // safe methods must not change state anyway

  const site = headers.get("sec-fetch-site");
  if (site) return site === "same-origin";            // add "same-site" only if you trust every subdomain

  const origin = headers.get("origin");               // fallback for browsers without Fetch Metadata
  if (origin) return TRUSTED.has(origin);             // exact match, not origin.startsWith(…)

  return false;                                       // neither header: not evidence of same-origin
}

The details that make it correct:

• Exact comparison. origin.startsWith("https://app.example.com") also accepts https://app.example.com.evil.test — a domain anyone can register.
• Fail closed. OWASP: "Missing headers and Origin: null are not evidence of a same-origin request." Reject, unless another defence (a valid token) passes.
• Know your own origin behind a proxy. If you compare against the Host header, take X-Forwarded-Host only from a proxy you trust. Configuring the expected origin is simpler.

When to add a token as well. If the endpoint must serve browsers without these headers, or same-site traffic can't be trusted, OWASP's token patterns still apply: the synchronizer token (a random value stored in the session and embedded in each form) for stateful apps, or the signed double-submit cookie for stateless ones. JSON APIs can also require a custom header such as X-CSRF-Token: a cross-site page can't add one without a CORS preflight your server would refuse.

Where the browser keeps your session token decides which attack you have to worry about. The Auth over HTTP unit covers how each option works; this is the security trade-off.

The cookie column needs CSRF defences — SameSite, the origin check, and for older browsers a token. The localStorage column needs none, which is why it's tempting. But it converts every XSS from "act inside the victim's tab" into "take the credential home". OWASP's HTML5 cheat sheet is direct: "Do not store session identifiers in local storage as the data is always accessible by JavaScript", while cookies "can mitigate this risk using the httpOnly flag".

Don't overstate HttpOnly, though. From the xss unit: a script running in your page can still call fetch('/api/…'), and the browser still attaches the cookie. OWASP's CSRF cheat sheet: "Cross-Site Scripting (XSS) can defeat all CSRF mitigation techniques!" — the script can read a CSRF token from the page, and its requests are same-origin, so Sec-Fetch-Site says same-origin. HttpOnly limits the damage (no stolen token, nothing to reuse later); only preventing XSS prevents the attack.

A sound default for a browser app with its own backend:

Set-Cookie: __Host-session=…; Path=/; Secure; HttpOnly; SameSite=Lax

• HttpOnly — script can't read it, so an XSS can't take it home.
• Secure — only sent over HTTPS.
• SameSite=Lax, written out — only Chromium applies it by default.
• The __Host- prefix — MDN: the browser rejects the cookie unless it has Secure, Path=/ and no Domain, so a sibling subdomain can't set or overwrite it.
• Plus the server-side origin check on every state-changing request, because SameSite doesn't separate sibling subdomains.

SameSite=Strict is stronger still, at the cost of users arriving from external links looking logged out on their first request.