Cross-Site Request Forgery

Try it out loud first. Then check yourself:

1. CSRF tricks a logged-in browser into sending a state-changing request because cookies are attached automatically
2. Attacker cannot read the response; the harm is the side effect (change email, transfer, add admin)
3. Classic fix: synchronizer token or signed double-submit cookie validated on every unsafe method
4. Chrome default Lax blocks cross-site POST cookies (2-min grace for new cookies with no SameSite set); top-level GETs still send them
5. State-changing GET endpoints, same-site subdomain takeovers, and XSS all defeat SameSite-only defenses

If the interviewer pushes back

• Why is an API that uses a bearer token in the Authorization header generally not CSRF-able?

Go deeper

• cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html