CSRF (Cross-Site Request Forgery)
One-line relationship: CSRF forges a request, riding on a session the browser attaches automatically. It’s the request-forgery sibling of clickjacking’s click-forgery — same C3 neighborhood, different mechanism, different defense.
What it is
You’re logged into your bank — an ambient session cookie sits in your browser. You then visit (or are redirected to) attacker.example, which contains a hidden auto-submitting form pointed at bank.example/transfer. The browser doesn’t know or care that the request originated from a different site; if the bank’s cookie is scoped to bank.example with no other protection, the browser attaches it to any request to that domain, including one an attacker’s page just silently fired. The bank server sees a well-formed, authenticated-looking transfer request and processes it.
Try it
You're logged into your bank in one tab (an ambient session cookie). In another tab, attacker.example auto-submits a hidden form to bank.example/transfer?to=attacker&amount=5000. The browser attaches your cookie automatically — that's the whole attack.
<form action="https://bank.example/transfer" method="POST">
<input name="to" value="attacker">
<input name="amount" value="5000">
<script>document.forms[0].submit()</script>
</form>
Ambient session cookie: present ✓
SameSite=Strict: no
CSRF token required: no
The lesson: CSRF doesn't steal anything — it forges a state-changing request and rides on a session the browser attaches automatically. Two independent defenses close it:SameSite=Strict(orLax) stops the browser from sending the cookie on a cross-site request in the first place; a per-session, per-form CSRF token means the attacker's forged request is missing something it can't guess. Either one alone usually suffices; real deployments often use both.
The two independent defenses
SameSite=Strict(orLax) cookies — tells the browser not to attach the cookie on a cross-site request in the first place.Strictblocks it on every cross-site navigation including top-level links;Lax(the modern browser default) allows it on top-level GET navigations but blocks it on cross-site POSTs — which is exactly the CSRF vector.- Anti-CSRF tokens — the server embeds a per-session (or per-form) random token in every state-changing form; a forged request from another origin has no way to know or guess it, so the server rejects the submission even if the cookie did get attached.
Either one alone usually stops the attack; defense-in-depth deployments use both, because SameSite protects cookie-based sessions specifically, while a CSRF token also protects against edge cases like subdomain takeover or misconfigured CORS.
What to take to the client
CSRF is the reason a bank’s session cookie should never be the only thing standing between a request and a transfer. SameSite=Lax is table stakes on any modern cookie; for high-value actions (payments, especially — see dynamic linking under PSD2), pair it with an explicit CSRF token and treat the two as independent, not redundant, layers.