A browser sends a cookie to whatever domain that cookie belongs to on every request to that domain, automatically, regardless of which page's JavaScript initiated the request — a form on an entirely unrelated site the user happens to have open in another tab can trigger a request to your bank's API, and the browser will happily attach the bank's own session cookie to it, because attaching cookies to their matching domain is exactly what a browser is designed to do. This single fact — that authentication can be ambient, carried automatically by the browser rather than deliberately attached by the code making the request — is the root of both cross-site request forgery and the reason cross-origin resource sharing exists as a control at all.
CORS and CSRF are frequently confused because both live at the browser boundary, and getting them backwards is a common, damaging mistake: CORS is a relaxation the server grants, telling a browser it is safe to let a specific other origin's JavaScript read the response of a cross-origin request; CSRF is an attack that does not need to read any response at all, because a form submission or a simple GET request can cause a side effect — transferring funds, changing an email address — without the attacker's page ever seeing what came back. A server can have a perfectly restrictive CORS policy and still be entirely vulnerable to CSRF, because CORS was never the control that CSRF requires.
This lesson builds the actual browser threat model these controls respond to: what a browser will do automatically that a server-to-server API call never would, and which control closes which specific gap that automatic behavior opens.
Analogy🏏Cricket
🏏 Think of it like cricket: A franchise's team hotel issues every player a room key that also, deliberately, unlocks the team meeting room down the hall, so a player heading to a tactical session doesn't need to fumble for a second key — the same credential, presented at either door, works because the hotel trusts that whoever's carrying a valid room key is a legitimate guest of the team. The risk this convenience creates has nothing to do with a stranger stealing the key; it's that the key works automatically, at any door it fits, regardless of what the player actually intended to do when they picked it up that morning — if someone tricked a player into badging into the wrong door while distracted, the key wouldn't stop to ask whether that was actually the player's intention. Teams that understood this risk added a second check at the meeting-room door specifically: a key alone isn't enough, you also confirm you meant to be there, because the key's automatic behavior was never designed to verify intent, only identity. Just as a hotel key works automatically at any matching door regardless of the guest's actual intention that moment, a browser attaches a session cookie to any request to a matching domain regardless of which page's script actually initiated it. Just as the meeting room needed a second, intent-specific check beyond the key, a state-changing request needs a second, intent-specific check beyond the cookie — a CSRF defense that verifies the request was actually intended by that page, not just automatically authenticated by the browser. The insight is that automatic authentication proves identity, not intention, and an attack that exploits the gap between those two doesn't need to steal anything at all — it only needs to trigger the automatic behavior at a moment the legitimate holder didn't choose.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.