Web Application Security · intermediate · ~10 min
Explain how CSRF abuses ambient credentials and the standard defenses.
CSRF makes a victim's browser send an authenticated state-changing request they didn't intend, exploiting cookies' automatic attachment (ambient authority). Defenses: unpredictable anti-CSRF tokens and SameSite cookies; token-in-header APIs are largely immune.
CSRF turns a victim's authenticated session into the attacker's tool for transfers, password changes, and admin actions. Knowing it hinges on auto-sent cookies explains both the bug and why SameSite/token defenses work.
Ambient authority. Cookies auto-attach → forged requests authenticate. Trigger. Attacker page auto-submits to the target. Tokens. Unpredictable, required on state changes. SameSite. Blocks cross-site cookie sending. Immune-ish. Bearer tokens added by JS.
CSRF tricks a logged-in victim's browser into making a state-changing request to a site they're authenticated to, without their intent.
Browsers attach cookies automatically to requests to a domain. So if a victim is logged into bank.com and visits an attacker page that auto-submits:
<form action="https://bank.com/transfer" method="POST">
<input name="to" value="attacker"><input name="amount" value="1000">
</form><script>document.forms[0].submit()</script>
the bank receives a fully-authenticated transfer — the cookie rode along. CSRF abuses ambient authority: the request is valid because the browser auto-authenticates it.
CSRF needs the action to rely solely on auto-sent credentials (cookies) and be predictable. Bearer-token APIs (token added by JS, not auto-sent) are largely immune.
Lax/Strict) — stop the cookie being sent on cross-site requests; strong modern baseline.CSRF abuses the browser's automatic cookie attachment to forge authenticated actions; the fixes are anti-CSRF tokens and SameSite cookies, while token-in-header APIs largely avoid it by design.