Cross-site request forgery: when it applies and how to stop it

What it is

A malicious page makes the victim's browser send a request to a site where the victim is logged in; the browser attaches the session cookie automatically, so the request looks authentic. OWASP's cheat sheet lists the defences: synchroniser tokens tied to the session, double-submit cookies, SameSite cookie attributes, and checking Origin/Referer for state-changing requests.

Why it matters

Any cookie-authenticated form or endpoint that changes state is exposed. Read-only endpoints and APIs whose credentials live in an Authorization header that the browser does not add on its own are not, which is why this wiki's bearer-key API needs no CSRF token.

How to apply

• Set session cookies with SameSite=Lax or Strict, Secure and HttpOnly.
• For cookie-authenticated state changes, require a token that the attacker cannot read (synchroniser pattern) and reject requests without it.
• Use POST/PUT/DELETE for state changes; never change state on GET.
• Check that Origin (or Referer) matches your site as an additional layer.

Pitfalls

SameSite=Lax still sends cookies on top-level GET navigations, which is why GET must be safe. CORS does not prevent CSRF; it governs reading responses, not sending requests. Tokens leaked into URLs are logged and shared.

Header-based checks as a first line

Current browsers send Origin on cross-origin requests and Sec-Fetch-Site on all requests. Rejecting state-changing requests whose Sec-Fetch-Site is cross-site (or whose Origin is not on an allowlist), combined with SameSite=Lax cookies, protects against CSRF without per-form tokens for current browsers. Keep synchronizer tokens where old clients or intentional cross-site flows must be supported.