CSRF Token.

A CSRF token is the canonical defence against Cross-Site Request Forgery, the attack ranked A05 in the OWASP Top 10 2013 and folded into "Broken Access Control" in later editions. The server generates a cryptographically random value, binds it to the user's session, and embeds it in HTML forms or exposes it for a custom request header. Because the same-origin policy prevents an attacker's page from reading the token, a forged cross-site request cannot supply the correct value and is rejected.

Three patterns dominate. The synchronizer token pattern stores the expected value server-side — the most robust but stateful. Double-submit cookies compare a cookie against a matching form field or header, needing no server state but vulnerable if an attacker can write cookies via a subdomain. The signed (HMAC) double-submit binds the token to the session to close that gap. Tokens must be per-session (or per-request for sensitive actions), long, and compared in constant time.

Defence in depth matters: since Chrome 80 (February 2020) unmarked cookies default to SameSite=Lax, which blocks most cross-site POSTs, but Lax still permits top-level GET navigations and not every browser enforces it — so tokens remain necessary. Pair them with Origin/Referer validation and strict CORS. Bearer-token APIs called only from JavaScript avoid ambient cookies and generally do not need a CSRF token, but they still require anti-replay and authorization controls.

flowchart TD
  A[User loads form] --> B[Server issues session-bound CSRF token]
  B --> C[Token in hidden field / custom header]
  C --> D[User submits state-changing request]
  D --> E{Token matches session value?}
  E -- Yes --> F[Process request]
  E -- No / missing --> G[Reject 403 - forged request]
  H[Attacker's cross-site form] -. cannot read token .-> G