Csrf Defense

CSRF defense

Cross-site request forgery abuses the browser's habit of attaching your cookies to every request to your site, including one triggered by a malicious page. The user is authenticated, so the forged request succeeds. The defense proves a request came from your own application, not merely from a browser that happens to hold a valid cookie.

Method

1. Set session cookies to SameSite=Lax or Strict. SameSite=Lax stops the cookie from riding along on cross-site POSTs, which kills most CSRF outright. Use Strict for high-value sessions where following a link should require re-establishing context. This is your baseline, not your only layer.
2. Add anti-CSRF tokens for state-changing requests. Issue an unpredictable per-session or per-request token, embed it in forms, and read it back from a header or body field. Reject any POST, PUT, PATCH, or DELETE whose token is missing or wrong. An attacker's page cannot read your token, so it cannot forge the request.
3. Keep GET safe and side-effect free. Never change state on a GET. Reserve mutations for POST, PUT, PATCH, DELETE. Method discipline is what lets SameSite and token checks target the requests that matter; a state-changing GET slips past both.
4. Pick the synchronizer or double-submit pattern deliberately. The synchronizer token stores the value server-side; double-submit puts it in both a cookie and a request header and compares them, useful for stateless APIs. Choose one and apply it consistently rather than mixing half of each.
5. Verify Origin and Referer on sensitive actions. For requests that move money or change credentials, check that the Origin (or Referer) header matches your host, and reject a mismatch. It is a cheap second signal that costs an attacker a header the browser will not let them forge.
6. Exempt token auth, not cookie auth. APIs authenticated by a bearer token in an Authorization header are not CSRF-prone, because the browser does not attach that header automatically. Confirm the endpoint truly requires the header and does not also accept the cookie, or the exemption reopens the hole.

Checks

• Do your session cookies carry SameSite=Lax or stricter, confirmed in the response headers?
• Does every state-changing endpoint reject a request with a missing or altered CSRF token?
• Can you confirm no GET endpoint mutates state?

Boundaries

CSRF defense assumes the session itself is sound; it does nothing against a stolen token or an XSS payload running on your own origin, which bypasses same-origin protections entirely. Login and logout forms need CSRF protection too. For pure token-in-header APIs with no cookie auth, these controls are unnecessary rather than optional.