<form action="https://bank.com/transfer" method="POST">
  <input name="to" value="attacker">
  <input name="amount" value="10000">
</form>
<script>document.forms[0].submit()</script>

Five lines of HTML on a malicious page. When a user who's logged into bank.com in another tab visits this page, the browser auto-submits the form, attaches their session cookie, and ten thousand dollars leave their account.

They didn't click anything. The malicious site didn't see their password. There was no XSS, no breach, no leak in the traditional sense. The browser did exactly what it was designed to do.

That's CSRF — Cross-Site Request Forgery — and it's been the classic "confused deputy" attack on the web for two decades. Let's walk through what makes it work, why CORS doesn't help, and the one cookie flag that mostly killed it around 2020.

Why the browser attaches your cookie to that request

Cookies belong to a domain. When you log into bank.com, the bank sets a session cookie in your browser:

Set-Cookie: session=abc123; HttpOnly

From that point on, every single request your browser sends to bank.com carries that cookie. Every page load. Every API call. Every image fetch. The browser does it automatically, without asking, and regardless of who triggered the request.

That last word is the door CSRF walks through. The browser attaches the cookie based on where the request is going, not where it came from. So when evil.com triggers a POST to bank.com/transfer, the browser sees a request destined for bank.com, looks up the cookies for bank.com, and attaches them. As far as the bank's server can tell, the request looks exactly like one the user submitted from inside the bank's own page.

This is the "confused deputy" idea. Your browser is the deputy. It has authority on your behalf (your cookies). And it's been tricked into using that authority for someone else's benefit. The server has no way to tell the difference, because from its point of view, there isn't one.

Why CORS doesn't help

It's a fair guess that CORS would stop this. The request is cross-origin. CORS controls cross-origin behavior. So CORS should block it, right?

It doesn't.

CORS controls what JavaScript can read from a cross-origin response. It says nothing about whether the request gets sent. And in CSRF, the attacker doesn't care about reading anything back. The damage is done by the time the response comes back.

There's a second wrinkle that makes this worse. Plain form submissions and image loads — both of which can carry cookies — don't trigger a CORS preflight at all. The browser just sends them. So a <form method="POST"> posting from evil.com to bank.com is, from the browser's perspective, an ordinary cross-site form submission. There's nothing for CORS to check, and nothing for the server to refuse.

CORS protects what JavaScript can see. CSRF is about what the server is tricked into doing. Different attacks, different layers.

What actually stops it

So what does? Two defenses. One classic, one modern.

The CSRF token (classic). When bank.com renders the transfer page, the server embeds a random, unguessable token in the form:

<form action="/transfer" method="POST">
  <input name="to">
  <input name="amount">
  <input type="hidden" name="csrf_token" value="9f3e8a7b12...">
</form>

The server checks the token when the form comes back. If it matches the one issued to this session, the request is legitimate. If it doesn't, or it's missing, the request is rejected.

This works because evil.com has no way to learn the token. Same-origin policy stops it from reading bank.com's pages, which is where the token lives. The attacker can build a fake form, but they can't put a valid token in it. The request arrives at the server with no token, the check fails, and the request is dropped. This is what Django, Rails, and Laravel do by default.

SameSite cookies (modern). Set the cookie like this:

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax

SameSite=Lax tells the browser: don't attach this cookie to requests coming from a different site, except for top-level GET navigations (clicking a link still works). So when evil.com triggers a POST to bank.com, the browser sees a cross-site origin and drops the cookie from the request. The bank receives an unauthenticated request and rejects it. The whole attack collapses at the cookie layer, before the server has to think about it.

Chrome started treating unspecified cookies as SameSite=Lax by default in 2020. Firefox and Safari followed. A huge chunk of CSRF on the web was quietly killed by that one change. If you're shipping anything new, set SameSite=Lax (or Strict for high-sensitivity cookies) explicitly, and you're most of the way there.

The one thing these defenses don't help with

Neither of them helps against XSS. If an attacker can run JavaScript inside your own origin — say, a forgotten dangerouslySetInnerHTML, an unsanitized rich-text input, a compromised dependency — the cookie is "same site" to that script, and any CSRF token in the page is readable. Both defenses assume your origin is trustworthy. If it isn't, CSRF is the smallest of your problems.

This is the boring lesson that keeps showing up across web security: each defense covers one layer, and stacking them is what keeps you safe. SameSite for CSRF. HttpOnly for cookie theft. CSP for XSS. None of them alone is enough. Together they cover most real cases.