How CSRF Works: The Confused Deputy and Its Preconditions

Before you can exploit or defend CSRF, you need a clear picture of why it is even possible. The whole bug rests on one browser behaviour and three conditions. Get those straight and every payload and bypass in this cluster reads clearly. Practice as you go on a free live target.

The browser attaches cookies by destination, not by origin

When your browser holds a session cookie for a site, it attaches that cookie to requests going to that site. The key word is destination. By default the browser does not care who started the request, the user typing a URL, clicking a link, a script, or a hidden form on a completely different site. If the request is going to the target, the target's cookies ride along.

That is deliberate and usually helpful: it is what keeps you logged in as you click around. But it means a request initiated by an attacker's page, aimed at a site where you are logged in, arrives carrying your authenticated session. The server sees a valid, authenticated request. CSRF is the art of making that request say something the user never intended.

The confused deputy

The classic framing is the confused deputy, and the deputy is the browser. A deputy is something that acts with authority on behalf of someone else. Your browser acts with the authority of your session: it can make changes to your account because it holds your cookie. CSRF confuses the deputy into using that authority for the attacker. The browser is not compromised and the cookie is not stolen. The browser is simply tricked into pointing its legitimate authority at an attacker-chosen action.

This is why stealing the session is not part of CSRF. The attacker never needs the cookie's value. They only need the browser to spend it on one request of their choosing.

The three preconditions

CSRF requires all three of these. Each one you can remove is a place to defend.

1. A worthwhile, state-changing action

CSRF forges a request, so the request has to do something worth forging. Changing an email or password, granting a role, transferring funds, updating settings, deleting a record. These write state. A read-only or idempotent action, like viewing a page or fetching a list, is not a CSRF target, because forging it accomplishes nothing: the attacker cannot see the response anyway, and nothing changed. The first question on any endpoint is "does this change something, and does that change matter?"

2. Cookie-based (ambient) authentication

The session must be carried by something the browser attaches automatically, which in practice means a cookie. That ambient authority is what the attacker borrows. If instead the application authenticates with a token that its own JavaScript reads from storage and puts in a custom header, a cross-site page cannot reproduce it, because the attacker's page cannot read the target's storage and cannot force the browser to add that header cross-site. Ambient cookie auth is the soil CSRF grows in.

3. Predictable request parameters

The attacker has to be able to build the entire request in advance, blind. Every parameter the server requires must be either known or guessable. If the request must include a value the attacker cannot predict, like a per-session CSRF token, they cannot construct a valid request and the attack fails. This is the precondition that a CSRF token deliberately removes, by adding exactly one unpredictable required parameter.

Putting it together

A CSRF attack is simply: find a state-changing action (precondition 1), confirm it is authenticated by an ambient cookie (precondition 2), and confirm you can predict every parameter (precondition 3). Then host a page that issues that request and get a logged-in victim to open it. The browser, the confused deputy, attaches the victim's cookie and the server obeys.

Every defense maps to breaking one precondition: a CSRF token removes predictability, SameSite narrows the ambient-cookie behaviour, re-authentication raises the bar on the worthwhile action, and read-only GET removes state-changing actions from the easiest delivery path.

Where to go next

Now that you know why CSRF works, see how it differs from its more powerful cousin in XSS vs CSRF, then get hands-on with the most common real finding in bypassing CSRF token validation. Or try the mechanism on a free live target.