CSRF

CSRF (Cross-Site Request Forgery) is an attack where a malicious site causes a victim’s browser to issue an authenticated request against a target site, leveraging the cookies the browser automatically attaches.

Classic example: you’re logged into bank.example.com. You visit evil.example, which contains <img src="https://bank.example.com/transfer?to=attacker&amount=1000" />. Your browser dutifully sends the request with your bank session cookies. The bank, unable to distinguish the legitimate origin, processes the transfer.

Modern defences:

• SameSite cookie attribute (default Lax in modern browsers) — blocks cookies from cross-origin POST requests.
• CSRF tokens — random server-issued tokens included in forms, checked on submit. Industry standard for decades.
• Origin/Referer header validation — defence in depth.
• Bearer-token authentication (in headers, not cookies) — immune to CSRF by default.

Modern frameworks (Django, Rails, Spring) ship CSRF protection enabled by default. The 2020 default-Lax cookie change effectively eliminated CSRF for most modern apps without any code changes.

Worked example

A 2008 vulnerability in many home routers illustrates the classic attack. The router’s admin interface lived at http://192.168.1.1/, used basic-auth cookies, and exposed a form like POST /apply.cgi?dns=... to change the DNS server. An attacker controlled a separate website that included an invisible auto-submitting form targeting that URL. A logged-in user visiting the malicious page would have their browser silently POST the form to their router, with the auth cookies attached automatically, and the DNS would be replaced with the attacker’s. From the router’s perspective every request looked legitimate. The fix the industry settled on: add a per-session CSRF token to the form, validate it on submit, and reject requests where the token is missing or wrong. A second fix arrived with SameSite=Lax cookies in Chrome 80 (2020) — the browser stops sending cookies on cross-site POSTs, defeating the attack at the cookie layer regardless of server-side checks.

When and why it matters

CSRF matters whenever an application authenticates users via cookies that are automatically attached by the browser — which is most legacy web apps and many modern ones. The mistake is assuming that “we’re an API, CSRF doesn’t apply”: if the API uses session cookies (rather than bearer tokens) and accepts form-encoded or simple JSON POSTs without preflight, it is vulnerable. The second mistake is relying solely on the Referer header — many corporate proxies and privacy tools strip it, breaking legitimate users. The modern minimum for a cookie-based app: set SameSite=Lax (or Strict for sensitive endpoints) on all auth cookies, validate a CSRF token on every state-changing request, and reject requests with mismatched Origin headers on JSON endpoints. For new APIs, switch entirely to bearer-token authentication via the Authorization header and the attack surface disappears. Reference: OWASP — Cross-Site Request Forgery.

The double-submit cookie pattern: when a backend can’t store per-session state, the CSRF token can be issued via a cookie and required to also appear in a custom request header. The browser auto-attaches the cookie on every request, but cross-origin sites cannot read its value to copy it into the header — the same-origin policy blocks the read. The server compares the two and rejects mismatches. This is the technique most modern single-page-app frameworks (Angular, Axios’ default config) use for CSRF defence on JSON APIs.

Why CSRF is increasingly irrelevant: the combination of SameSite=Lax defaults (Chrome 80, 2020), bearer-token authentication, and CORS preflight on non-simple requests has shrunk the practical attack surface to legacy form-encoded endpoints that still rely on cookies. For new APIs built today, opting out of cookies entirely and using Authorization: Bearer <token> headers eliminates CSRF without ceremony. The OWASP risk-ranking moved CSRF out of the Top 10 list in 2017 because of how widespread the structural defences had become. Reference: OWASP CSRF Prevention Cheat Sheet.