CSRF Attacks Explained: The Web's Quiet Confused Deputy Problem

The name "cross-site request forgery" sounds like it needs a security degree to understand. The actual mechanism is closer to a practical joke that happens to work because your browser is a little too trusting.

One tab you trust, one tab you should not, and a browser that treats them as equally credible.

In this post

1. The "confused deputy" idea, explained without the jargon
2. A concrete, harmless walkthrough
3. Why your browser cooperates without meaning to
4. What CSRF can actually accomplish
5. How developers actually prevent it
6. What you can check as a non-developer site owner

Cross-site request forgery, almost always shortened to CSRF, relies on a specific quirk of how browsers handle logged-in sessions. It has a formal name for this pattern too, the confused deputy problem, which is a more useful way to think about it than the technical acronym.

The "confused deputy" idea, explained without the jargon

A confused deputy is something with legitimate authority that gets tricked into misusing that authority on someone else's behalf. Your browser, while you are logged into a site, is that deputy. It is carrying your login session, your proof of identity, and it will attach that proof to requests automatically, without asking you each time whether this specific request is actually one you meant to make. CSRF exploits that automatic behavior. It is not about stealing your password or breaking into your account directly, it is about tricking your already-logged-in browser into performing an action you never chose to take.

A concrete, harmless walkthrough

Picture a banking site with a poorly protected transfer feature that processes a request like this when you click a legitimate "transfer funds" button:

GET https://examplebank.com/transfer?amount=500&to=friend

If that request works purely because your browser is logged in, with no additional check confirming you specifically meant to trigger it, an attacker can embed that exact URL as an invisible image tag on a completely unrelated page. Something like:

<img src="https://examplebank.com/transfer?amount=500&to=attacker" width="0" height="0">

If you happen to be logged into that bank in another tab while visiting the attacker's page, your browser loads that image tag automatically, sends the request, and attaches your valid session cookie without asking you anything. The bank's server sees a logged-in user requesting a transfer and has no way to know you never actually clicked a transfer button at all, only that the request arrived with valid credentials attached.

Why your browser cooperates without meaning to

This works because of how cookies function by default. Once you log into a site, your browser stores a session cookie and automatically attaches it to every subsequent request to that domain, regardless of which page or which tab triggered the request. That behavior is not a flaw exactly, it is how persistent logins are supposed to work, letting you navigate a site without re-authenticating on every single click. CSRF exploits the fact that "this request has a valid session cookie" and "the user genuinely intended this specific action" are two different things that a naive server implementation can end up treating as the same thing.

What CSRF can actually accomplish

The scope depends entirely on what actions a site allows through simple requests without additional verification. Historically documented CSRF vulnerabilities have enabled unauthorized fund transfers, changed account email addresses and passwords, which can lead directly to full account takeover, posted content or messages on a victim's behalf, and modified account settings or permissions. The severity tracks closely with how sensitive the action is and how little additional confirmation the vulnerable feature required.

How developers actually prevent it

The standard, well-established defense is a CSRF token, a unique, unpredictable value generated by the server and embedded in legitimate forms on the actual site. When a form submits, the server checks that this token is present and correct before processing the request. An attacker's forged request, coming from a different site entirely, has no way to know or include that token, so the server rejects it even though the session cookie itself is valid. This is considered baseline practice today, and virtually every modern web framework includes CSRF protection built in by default rather than requiring developers to implement it from scratch.

A second, complementary defense browsers themselves now provide is the SameSite cookie attribute, which restricts when a browser is willing to send a cookie along with a cross-site request in the first place. The OWASP community page on CSRF covers both defenses in more technical depth for anyone building or reviewing this themselves.

Why the harmless example above stops where it does: understanding the confused deputy pattern is genuinely useful for evaluating whether a site or application you run is protected. Walking through how to craft a working exploit against a real, live, non-consenting target is a different thing entirely, and it is not something this post is going to do.

What you can check as a non-developer site owner

• Ask your developer directly whether the site's forms include CSRF token protection, most modern frameworks handle this automatically, but custom-built or older code may not
• Confirm your framework or CMS is on a currently supported version, since CSRF protections have improved and become more consistent across major frameworks over time
• Check that sensitive actions, password changes, fund transfers, account deletion, require some form of re-confirmation, not just a single automatic request
• If you run custom code handling anything sensitive, ask specifically whether SameSite cookie attributes are set appropriately for your use case

CSRF is not a flashy, headline-grabbing vulnerability the way some others are, but it has caused real, serious breaches precisely because it exploits something so ordinary, a browser doing exactly what it is supposed to do with a login session. Understanding the confused deputy framing is usually enough to have an informed conversation with whoever builds or maintains the sites you are responsible for.