What Is CSRF?

Chapter 1

What CSRF Is & Why It Works

The confused deputy, ambient authority, and a concrete attack walkthrough

Cross-Site Request Forgery (CSRF) tricks a logged-in user's browser into making a request the user never intended — to a site they're already authenticated with. The attacker can't read the response or steal the session; they simply cause an action to happen using the victim's existing authority. This chapter explains the mechanism that makes that possible, because every defence later in the course targets one specific link in this chain.

The Core Idea: A Confused Deputy

CSRF is a classic confused deputy problem. A "deputy" is something that acts on behalf of someone with more authority than the requester. Here the deputy is your browser: it holds your authority for yourbank.com (your session), and it will faithfully attach that authority to any request to that site — even a request initiated by a totally unrelated, malicious page. The browser is "confused" into using your authority for the attacker's intent.

CSRF rides existing authority — it doesn't steal credentials

This is the single most important framing of the whole course: a CSRF attacker never learns your password or session cookie. They don't need to. They borrow the authority your browser already carries, to perform an action you didn't choose. So CSRF is an attack on intent (did the user mean to do this?), not on authentication (is this really the user?). The user genuinely is authenticated — that's exactly what the attacker exploits.

Why the Browser Cooperates: Ambient Authority

The enabling mechanism is ambient authority — authority that's applied automatically, in the background, without the requesting code having to present it explicitly. Cookies are the textbook example:

The browser rule	The consequence for CSRF
Cookies for a domain are attached to every request to that domain…	…even when the request was triggered by a different site
This happens automatically, with no action from the page making the request	The attacker's page doesn't need (or get) access to the cookie itself
The server sees a request with a valid session cookie	It looks indistinguishable from a genuine one

That last row is the crux: from the server's perspective, a forged request carrying your valid session cookie looks exactly like a legitimate one. There's nothing in the cookie alone to reveal whether you intended the request or an attacker's page did. That ambiguity is the vulnerability.

A Concrete Attack: The Forged Money Transfer

Suppose yourbank.com performs transfers via a simple form POST:

<!-- the legitimate form on yourbank.com -->
<form action="/transfer" method="POST">
  <input name="to" value="...">
  <input name="amount" value="...">
</form>

Now the attacker hosts this on evil.com and lures you to visit it (a link, an ad, an email):

<!-- on evil.com — auto-submits the moment the page loads -->
<form action="https://yourbank.com/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="attacker-account">
  <input type="hidden" name="amount" value="5000">
</form>
<script>document.getElementById('f').submit()</script>

You log into yourbank.com — your browser now holds a valid session cookie for it.

In another tab (or later, still logged in) you visit evil.com.

Its hidden form auto-submits a POST to yourbank.com/transfer.

The browser automatically attaches your yourbank.com cookie (ambient authority).

The bank sees a valid, authenticated request and executes the transfer — to the attacker.

You never clicked "transfer." You may never even see it happen — the attacker doesn't need to read the response, only to trigger the action. That's a complete CSRF attack.

The three preconditions — remove any one and the attack fails

A CSRF attack needs all three of these, which is why defences target them: (1) the action is driven entirely by the request (the server relies only on the cookie to authorize it); (2) the request uses only parameters the attacker can predict/forge (no secret value they can't know); (3) the victim's browser will auto-send their credentials cross-site. Every defence in this course — tokens, SameSite cookies, origin checks — works by breaking precondition (2) or (3). Keep this triad in mind; it's the skeleton key to the whole topic.

What CSRF Is Not

Precision here prevents confusion later (Chapter 4 expands this):

Not credential theft — the attacker never obtains your password or cookie; they ride the session you already have.
Not data theft — classic CSRF is "write-only." The attacker causes an action but generally can't read the response (the same-origin policy blocks that). CSRF is about doing, not reading.
Not XSS — XSS runs the attacker's script on the victim site; CSRF runs no script on the target at all, it just sends a request to it from elsewhere. Different attack, different defence.

Your admin-login token error is this machinery working — a preview

The "Invalid CSRF token" you hit logging into your own admin page is the defence from this course in action (the synchronizer token, Chapter 5). It's rejecting a request whose anti-CSRF token didn't match your session — usually a stale token on a login page rather than a real attack. We'll diagnose exactly why it happens (and why the back button "fixes" it) in Chapters 5 and 10, once the token mechanism is on the table.

Hands-On Exercises

Exercise 1

In your own words, explain the "confused deputy" framing of CSRF: who is the deputy, whose authority does it hold, and how is it confused? Then state precisely why the attacker does not need to steal the session cookie for the attack to work.

📄 View solution

Exercise 2

Write out the five steps of the forged-transfer attack as a sequence, labelling at which step the victim's cookie gets attached and by whom. Then identify which single step would be prevented if the bank required a secret value the attacker couldn't predict.

📄 View solution

Exercise 3

List the three preconditions a CSRF attack requires. For each, give a one-line example of a defence (from anywhere you know, or guess) that would remove it. This builds the mental map the rest of the course fills in.

📄 View solution

Chapter 1 Quick Reference

CSRF = tricking a logged-in user's browser into making an unintended request to a site they're authenticated with
Confused deputy — the browser is the deputy; it applies your authority to a request an attacker initiated
Ambient authority — cookies auto-attach to every request to their domain, even cross-site ones
A forged request with your valid cookie looks identical to a genuine one to the server — that ambiguity is the vulnerability
CSRF attacks intent, not authentication — no password or cookie is stolen
Classic CSRF is write-only — it causes an action; it generally can't read the response (same-origin policy)
Three preconditions: cookie-only authorization · forgeable parameters · cross-site credentialed requests — break any one to stop it
Next chapter: how the browser enables it — cookies, credentialed requests, and which elements send them cross-site