What are the three main CSRF protection mechanisms?

CSRF tokens (a secret the attacker can't read), the SameSite cookie attribute (browser won't send the cookie cross-site), and double-submit cookies (token in both cookie and request, must match).

* Each defence removes a different prerequisite of the attack — a secret to supply, a credential to ride on, or a pair that must match. *

All three exploit the same asymmetry: a cross-site attacker can make your browser send a request, but cannot read anything that comes back from the target site. So each defence demands a value the attacker would have to read in order to forge.

1. CSRF Token (Synchronizer Token Pattern):

• Server generates a random token and stores it in the session
• Token is sent in the HTTP response body or a header
• The client must include it with each modifying request
• Server verifies the token matches the one in the session
• Why it works: the token lives in the page's HTML, and the same-origin policy stops the attacker's page from reading it. Being random and per-session, it also can't be guessed — so a forged request arrives with no token or a wrong one and is rejected.

2. SameSite Cookie Attribute:

• Set on the session cookie: SameSite=Strict or SameSite=Lax
• The browser then won't attach that cookie to cross-site requests
• Strict: never sent cross-site
• Lax: sent only with top-level navigations that use a safe method — a normal link into the site still works, but a cross-site form POST does not, whether it fires quietly in a hidden frame or navigates the whole window
• Why it works: it removes the ammunition rather than checking the request. The forged POST still arrives, but unauthenticated, so the server sees an anonymous request and refuses. It needs no application code at all — one attribute — which is why it is the cheapest layer. The trade-off is that it depends on the browser honouring it, and Strict can break legitimate inbound links.

3. Double Submit Cookie:

• Set the CSRF token as a cookie and require the client to copy it into a request parameter
• The attacker can trigger the request, and the cookie rides along automatically — but they cannot read the cookie to copy its value into the parameter
• Server verifies the two values match
• Why it works: the server needs no per-session state, since it only compares the request against itself. That makes it the usual choice for stateless or horizontally scaled APIs, at the cost of being weaker than a synchronizer token if any subdomain can be compromised to write cookies.

In practice, combine them: SameSite as a broad browser-enforced default, plus a token so the protection does not rest on browser behaviour alone.

Go deeper:

• web.dev — SameSite cookies explained — exactly which requests still carry the cookie under Strict and Lax.
• OWASP CSRF Prevention Cheat Sheet — how to pick between the token patterns, and their failure modes.