CSRF, and the cookie flag

<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.