Cross-Site Request Forgery (CSRF)
An attack that forces an authenticated user to execute unwanted actions on a web application in which they are currently authenticated.
Detailed Explanation
CSRF exploits the fact that browsers automatically include cookies (like session IDs) in every request to a domain. If you are logged into your bank and visit a malicious site, that site could trigger a hidden POST request to your bank to transfer money. Defenses include using 'SameSite' cookie attributes and including unique CSRF tokens in every state-changing request.
Quick Summary
CSRF rides the user's existing session to perform actions the user didn't intend. A victim clicks a link or visits an attacker page, and their browser silently sends an authenticated request to the target site with their cookies attached.
Key Takeaways
- Mitigated by SameSite=Lax or Strict cookies, which prevent the browser from sending session cookies on cross-site requests.
- Anti-CSRF tokens (random per-session value the attacker can't predict) are the legacy belt-and-suspenders defense.
- Only affects state-changing requests; GETs should be idempotent and not require CSRF protection (but shouldn't change state either).
- APIs using bearer tokens in Authorization headers (not cookies) aren't vulnerable to classic CSRF, the browser doesn't auto-attach headers.
- Modern browsers default to SameSite=Lax for cookies without an explicit setting, raising the floor.
When to use it
- Audit checklist: every state-changing endpoint that uses cookie auth needs CSRF protection.
- Framework integration, Rails, Django, Laravel ship CSRF middleware enabled by default.
- Bank, e-commerce, and admin panels where a single forged POST can do real damage.
- Security training to explain why double-protection (SameSite + tokens) is worth the small cost.
Common Mistakes
- Relying on referer/origin checks alone, they can be stripped or spoofed in some browsers/proxies.
- Skipping CSRF protection on JSON endpoints because "no form submission can hit JSON", old browsers and CORS edge cases say otherwise.
- Sending the CSRF token in the same cookie as the session, same-cookie attacks defeat the scheme.
- Using CSRF tokens for read-only GETs (overhead with no benefit) or omitting them on PATCH/DELETE (real risk).
Cross-Site Request Forgery (CSRF), Frequently Asked
Does SameSite=Lax fix CSRF entirely?
It blocks classic CSRF in modern browsers for cookie-auth'd sites, but corner cases remain (top-level navigations with GET, browsers that don't enforce SameSite). Keep CSRF tokens as a defense in depth, especially for high-value actions.
Do single-page apps need CSRF protection?
If they authenticate with cookies, yes, same risk as server-rendered sites. If they use bearer tokens in Authorization headers, classic CSRF doesn't apply because browsers won't auto-attach the header on a cross-site request.
What's the double-submit cookie pattern?
Server sets a random value as a cookie and the JS reads it and sends it back in a header on every request. The server checks the header equals the cookie. Stateless and effective when SameSite isn't reliable.