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.

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:

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:

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

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.

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.

Hands-On Exercises

Chapter 1 named the mechanism — ambient authority. This chapter looks at the browser machinery in detail: how cookies get attached, what "credentialed request" really means, and crucially which ways of making a request will carry the victim's cookies cross-site. Knowing exactly which elements are dangerous (and which aren't) is what lets you reason about both attacks and defences precisely.

How Cookies Get Attached — by Destination, Not Origin

The single rule behind all of CSRF: the browser attaches a cookie based on where the request is going, not where it came from. When a request heads to yourbank.com, the browser looks up the cookies stored for yourbank.com and includes them — and it does not care which page initiated that request. A script on evil.com triggering a request to the bank gets the bank's cookies attached just the same.

"Credentialed" Requests

A credentialed request is one the browser sends with the user's ambient credentials (cookies, HTTP auth, client certs) attached. Whether a request is credentialed depends on how it's made:

• Navigations & form submissions — always credentialed. A <form> POST or following a link always carries cookies for the destination. This is the CSRF workhorse.
• Resource loads (<img>, <script>, <iframe>) — credentialed. They fetch their target with cookies attached, which is why a GET that changes state is forgeable via an image tag.
• fetch / XMLHttpRequest — credentialed only if asked. By default cross-origin fetch sends no cookies; you must opt in with credentials: 'include' — and even then the response is gated by CORS.

The Critical Asymmetry: Sending vs Reading

Here's the distinction that explains why classic CSRF is "write-only," and it trips up almost everyone at first:

The Same-Origin Policy (SOP) stops one origin from reading another origin's responses — so the attacker's page can't see your bank balance. But SOP was never designed to stop the browser from sending a cross-site request in the first place. CSRF lives entirely in that gap: sending is allowed even though reading is forbidden. The attacker doesn't need to read; causing the action is the whole goal.

The Role of HTTP Methods — and "Simple Requests"

Methods matter because of how easily each can be forged without any special permission:

A <form> can only send GET or POST, and only with three "simple" content types (application/x-www-form-urlencoded, multipart/form-data, text/plain). These are exactly the requests a browser will send cross-site without a CORS preflight (the automatic OPTIONS check). Anything beyond that — a DELETE, or a Content-Type: application/json — triggers a preflight the attacker's forged request can't satisfy, so it's effectively blocked.

Two Methods, Two Honest Misuses

A recurring root cause: state-changing actions exposed over GET. Because <img>, <script>, and links all issue credentialed GETs silently, an endpoint like GET /account/delete?id=5 can be fired by merely loading an image tag on any page — no form, no script even needed. The HTTP spec says GET must be safe (no side effects) for exactly this reason. POST is not magically secure either, but at least it can't be triggered by a bare <img>.

Hands-On Exercises

With the mechanism understood (Chapters 1–2), this chapter is the attacker's toolkit — assembled here so you can recognize and test for these patterns defensively, which is the whole point of studying them. We'll build each forgery type from simplest to most capable, note what each requires of the target endpoint, and look at how attacks are delivered.

Level 1: GET Forgery with an Image Tag

The simplest possible attack needs no form and no script — just a state-changing endpoint exposed over GET. A single tag on any page the victim loads fires a credentialed request:

Because <img> issues a credentialed GET (Chapter 2), the browser attaches the victim's cookies and the unsubscribe happens. display:none hides the broken-image icon so there's no visual tell. This works only because the endpoint violated the rule that GET must be side-effect-free — which is exactly why that rule exists.

Level 2: POST Forgery with an Auto-Submitting Form

Most state changes are (correctly) POST, which an <img> can't produce. The standard attack is a hidden form that submits itself on load — the canonical CSRF payload:

The form's action points cross-site to the target; hidden inputs supply the attacker-chosen parameters; onload auto-submits so no click is needed. Changing the victim's account email is a favourite because it often enables a follow-up password reset — a foothold for full account takeover.

Level 3: Forgery via fetch (and its limits)

An attacker can also use fetch, but Chapter 2's rules bite here. To send cookies cross-site they must opt in, and they're confined to "simple" requests or they'll trigger a blocking preflight:

Note what the attacker cannot do: set a custom header, or send application/json — either triggers a preflight their origin can't pass. So fetch gives them no more power than a form for classic targets; the form is usually simpler and works even with scripting disabled. This limitation is the seed of several defences.

GET vs POST Forgery, Side by Side

Delivery: Getting the Victim to the Payload

The forgery only fires if the logged-in victim loads the attacker's page. Common delivery vectors:

• A link in an email, message, or forum post leading to the attacker's page.
• A malicious or compromised ad (malvertising) on an otherwise-legitimate site.
• An embedded resource — for GET attacks, the payload can be an <img> posted into any site that allows user images (a forum signature, a comment).
• The victim simply being logged in elsewhere — they don't need to "do" anything beyond having an active session and opening the page.

What the Attacker Still Can't Do

Keeping the limits sharp (from Chapter 2) helps you scope risk correctly:

• Can't read responses — so they can't exfiltrate data this way; CSRF is about causing actions.
• Can't forge requests needing unpredictable values — a secret token they can't guess blocks the request entirely (Chapter 5).
• Can't set custom headers or JSON bodies cross-site without a preflight — limiting attacks to simple requests.
• Can't act if the cookie isn't sent — SameSite (Chapter 7) can strip the credential from the forged request.

Each "can't" is a defence the rest of the course makes concrete. Next we clear up the most-confused boundary in web security: CSRF versus XSS versus SSRF.

Hands-On Exercises

These three acronyms look alike, get muddled constantly, and have completely different mechanisms and defences. Confusing them leads to applying the wrong fix — the dangerous "I added CORS, so I'm safe from CSRF" class of mistake. This mid-course checkpoint pins down each one precisely and, just as importantly, how they relate.

One-Line Definitions

The clearest way to keep them apart is to ask who is tricked into acting: CSRF tricks the browser, XSS injects script that runs in the page, SSRF tricks the server. Two are "cross-site," one is "server-side" — and that word swap (Scripting vs Request Forgery) is where most confusion starts.

CSRF vs XSS — The Pair People Mix Up Most

Both involve a victim and a malicious payload, but the capability gap is enormous:

What XSS Looks Like (Briefly)

XSS happens when untrusted input is rendered into a page without proper encoding, so it executes as code rather than displaying as text:

The fix is the opposite discipline from CSRF's: encode output so input can never become executable markup, plus a Content-Security-Policy to restrict what scripts may run. Note these defences have nothing to do with tokens or SameSite — different bug, different toolbox.

SSRF — The Odd One Out

SSRF is server-side and unrelated to the victim's browser at all. The attacker abuses a server feature that fetches a URL — an "import from URL," a webhook, an image-from-link — by supplying a URL pointing somewhere the server can reach but the attacker normally can't:

Classic SSRF targets internal-only services: cloud metadata endpoints, internal admin panels, databases — things firewalled from the internet but reachable from the server itself. The defence is again wholly different: validate/allowlist outbound URLs, block internal IP ranges, and isolate the metadata endpoint. SSRF shares the words "Request Forgery" with CSRF but the forger is the server, not the browser — opposite side of the connection.

The Memory Hook

How They Can Combine

They're distinct, but real attacks chain them:

• XSS → CSRF isn't even needed — XSS can do everything CSRF can and more, same-origin. (This is why XSS outranks CSRF in severity.)
• CSRF → SSRF — a CSRF that hits an internal admin endpoint, or that triggers a server-side fetch feature, can become a delivery vector for SSRF.
• Defence independence — because the mechanisms differ, you need all three sets of defences; fixing one does nothing for the others. A token-protected app can still be wide open to XSS or SSRF.

Hands-On Exercises

Now the defences. The synchronizer token pattern is the oldest and most robust CSRF defence, and the one behind the "Invalid CSRF token" message you hit on your admin login. It works by attacking precondition #2 from Chapter 1 — forgeable parameters — by requiring every state-changing request to carry a secret the attacker cannot know.

The Core Idea

The server generates a random, unpredictable token, ties it to the user's session, and embeds it in every form it serves. A genuine request (from the server's own page) includes the token; a forged request (from evil.com) cannot, because the attacker can't read the token out of your page (Same-Origin Policy, Chapter 2). The server rejects any state-changing request whose token is missing or wrong.

The Lifecycle: Generate → Embed → Submit → Validate

What It Looks Like in Code (Express)

The token must be sent in the request body or a header — never only in a cookie, because a cookie auto-rides on forged requests too (that's the whole problem). The defining property is that the token travels somewhere the attacker would have to read or write, which cross-site they cannot.

Per-Session vs Per-Request Tokens

This table is the crux of your login mystery. Per-request rotation is more secure but notoriously breaks the back button and multi-tab usage, because an old page holds a token the server has already rotated away from.

Generating a Good Token

The token's security rests entirely on being unguessable. Use a cryptographically secure random generator, not Math.random():

Compare tokens with a constant-time comparison (e.g. crypto.timingSafeEqual) to avoid leaking information through timing. And validate on every state-changing request — a single unprotected POST endpoint is all an attacker needs.

Hands-On Exercises

The synchronizer token (Chapter 5) requires the server to store a token per session. That's fine for stateful apps, but adds friction for stateless backends and APIs that don't keep server-side session state. The double-submit cookie pattern achieves CSRF protection without server-side storage — at the cost of some subtle pitfalls this chapter makes explicit.

The Core Trick

The server sends the CSRF token as a cookie, and the client-side JavaScript reads that cookie and copies its value into a request header (or body field) on each state-changing request. The server then checks that the cookie value and the header value match. No server-side token store is needed — the server just compares the two copies the request itself carries.

Why It Stops CSRF

The cookie rides automatically on a forged cross-site request (ambient authority) — but the attacker cannot read it to copy its value into the header, because of the Same-Origin Policy (Chapter 2). So a forged request arrives with the cookie but no matching header, and validation fails. The defence rests entirely on the asymmetry: the cookie is auto-sent, but only same-origin JavaScript can read it to set the header.

Synchronizer vs Double-Submit

The Big Pitfall: Subdomains Can Write Your Cookie

Double-submit's security assumes the attacker can't control the cookie value. But cookies have a weaker isolation model than the same-origin policy: a sibling or compromised subdomain can set a cookie on the parent domain. If evil.example.com (or an XSS on any subdomain) can write the csrf cookie for .example.com, an attacker can plant a known value — then put that same known value in the header of a forged request, and the two match.

The Signed / HMAC Variant

The hardened form binds the token to the user's session so it can't be forged by merely setting a cookie:

Now the server doesn't blindly trust the cookie; it verifies the token is one it issued for this session. This restores the property that an attacker who can only set a cookie (but not read the session secret) can't produce a valid token — closing the cookie-injection hole while staying stateless.

The SPA-Friendly Variant You've Probably Seen

Frameworks like Angular and Django (with the right config) ship a double-submit flow out of the box: the server sets a cookie named XSRF-TOKEN, and the framework's HTTP client automatically reads it and sends it back as an X-XSRF-TOKEN header on every request. If you've used Angular's HttpClient and wondered where CSRF protection came from, this is it — double-submit, automated.

Hands-On Exercises

Tokens (Chapters 5–6) defend by adding a secret to the request. SameSite attacks CSRF from a different angle — precondition #3 (Chapter 1): it tells the browser not to send the cookie cross-site in the first place. It's a one-line cookie attribute that, combined with a 2020 change to browser defaults, reshaped the entire CSRF landscape.

The Attribute

SameSite is set on a cookie and controls whether the browser attaches it to cross-site requests. It has three values:

How Each Value Affects CSRF

• Strict — the cookie is never sent on any cross-site request, so forged requests arrive with no session cookie at all → CSRF fully blocked. The cost: even a legitimate inbound link from another site (e.g. an email link to your dashboard) arrives logged-out, which hurts UX.
• Lax — the cookie is sent on top-level GET navigations (so following a link to your site keeps you logged in) but not on cross-site POSTs, forms targeting your site, or background subresource requests. This blocks the classic POST-form CSRF while preserving normal link UX — the sweet spot, and now the default.
• None — the old behaviour: cookie sent on all cross-site requests. This is what CSRF exploited. Now requires Secure, and is only appropriate for cookies that genuinely need cross-site use (e.g. third-party embeds, SSO).

Why Lax Stops the Classic Attack

Recall the canonical attack (Chapter 3): an auto-submitting hidden POST form on evil.com. With SameSite=Lax, the browser will not attach the session cookie to that cross-site POST, because Lax only sends cookies on top-level GET navigations — not POSTs, not subresource requests. The forged POST arrives unauthenticated, and the server treats it as a logged-out request. The hidden-form workhorse of CSRF is neutralized by a single cookie attribute.

"Site" vs "Origin" — a Crucial Distinction

SameSite operates on the concept of site (the registrable domain, e.g. example.com), not origin (scheme + host + port). This is looser than the Same-Origin Policy:

The middle row is the catch: a sibling subdomain is same-site, so SameSite won't stop a malicious or compromised subdomain — which ties directly to the cookie-injection concern from Chapter 6. SameSite defends the cross-site boundary, not the cross-origin-but-same-site one.

Practical Recommendation

For a typical session cookie: SameSite=Lax (the default, but set it explicitly), plus Secure and HttpOnly. Use Strict for the highest-sensitivity cookies where the "arrive logged out from external links" cost is acceptable (or pair Strict with a Lax "read" cookie). Reserve None for cookies that truly require cross-site sending, always with Secure. And — the recurring theme — layer it with anti-CSRF tokens rather than relying on SameSite alone.

Hands-On Exercises

Each defence so far has gaps: tokens can be misimplemented, SameSite has the site-vs-origin and GET holes, double-submit has cookie injection. Defence in depth is the discipline of layering independent mechanisms so that an attacker must defeat all of them — and a single misconfiguration doesn't expose you. This chapter covers the supplementary defences and how to stack them.

Checking the Origin / Referer Header

On a cross-site request, the browser sets an Origin header (and usually Referer) identifying the page that initiated it — and the attacker's page cannot forge or remove these on a cross-site request (they're browser-controlled). So the server can simply check: did this state-changing request come from my own origin?

Requiring a Custom Request Header

From Chapter 2: a cross-site attacker cannot set a custom header on a simple request without triggering a CORS preflight they can't pass, and an HTML form can't set headers at all. So requiring a header like X-Requested-With: XMLHttpRequest on state-changing endpoints means a classic form/img forgery simply can't produce a valid request.

Re-Authentication & Step-Up for Sensitive Actions

The strongest layer for the highest-value actions doesn't rely on request shape at all: require the user to prove intent directly — re-enter their password, confirm with a one-time code, or pass an MFA challenge — for operations like changing email/password, deleting an account, or making a payment.

This defeats CSRF by construction: even a perfectly forged request can't supply the current password or live MFA code, because the attacker doesn't know them (Chapter 3's "account takeover via change-email" is exactly what this stops). It's friction, so reserve it for genuinely sensitive operations — but for those, it's the most robust defence available.

The Layered Stack

A well-defended state-changing endpoint combines several independent checks — an attacker must beat every one:

What to Actually Ship

For most apps the pragmatic, strong baseline is: SameSite=Lax + anti-CSRF tokens (via a maintained library) + safe-GET discipline, with Origin checks as an easy extra layer and re-authentication on the handful of truly sensitive endpoints. You don't need every layer everywhere — you need enough independent ones that no single failure is catastrophic, weighted toward your highest-value actions.

Hands-On Exercises

Classic CSRF assumed server-rendered pages and cookie sessions. Modern apps — SPAs talking to JSON APIs, mobile clients, token-based auth — change the picture significantly. The single most important question for any endpoint is: how does it authenticate the request? Because that answer determines whether CSRF even applies.

The Decisive Question: Cookies or Not?

CSRF exists only because credentials are sent automatically (ambient authority, Chapter 1). So the dividing line is whether your auth credential is auto-attached by the browser:

Where Teams Get This Wrong: JWT in a Cookie

A very common pattern is "we use JWTs, so we're stateless and CSRF-safe." But where the JWT is stored decides everything:

The "JSON-Only / Custom Header" API Defence

Many JSON APIs lean on the Chapter 2 fact that a forged HTML form can't set headers and can't send application/json without a preflight. So an API that requires Content-Type: application/json and rejects everything else (or requires a custom header) blocks classic form-based CSRF:

SPA + Cookie Session: The Double-Submit Sweet Spot

A very common modern setup is an SPA that still uses a cookie session (often the simplest, most secure option since the session cookie can be HttpOnly). Here the double-submit cookie (Chapter 6) fits perfectly: the SPA's HTTP client reads the XSRF-TOKEN cookie and echoes it in an X-XSRF-TOKEN header automatically. This is exactly what Angular's HttpClient and Axios (with config) do out of the box.

Framework Built-Ins — Don't Roll Your Own

Decision Guide

• Cookie/session auth (SSR or SPA) → SameSite + anti-CSRF tokens (synchronizer for SSR, double-submit for SPA). CSRF fully applies.
• Header bearer token (no cookies) → no classic CSRF; focus on XSS (token theft) and token handling instead.
• JWT in a cookie → treat exactly like a session cookie: full CSRF defences required.
• Mobile / native client (no browser) → no CSRF (no ambient cookie behaviour); standard token auth.

Hands-On Exercises

The final chapter turns understanding into practice: how to test for CSRF on your own apps, the broken-defence patterns that look protected but aren't, a copy-pasteable hardening checklist — and the proper, deployable fix for the admin-login token error that started this whole course.

How to Test for CSRF

Testing your own endpoints follows a simple manual procedure (and tools automate it):

1. Capture a legitimate state-changing request (DevTools → Network, or Burp Suite's proxy).
2. Identify the auth — is it a cookie (CSRF-relevant) or a header token (not classic CSRF)? (Chapter 9)
3. Strip the anti-CSRF token (and any custom header) and replay the request with only the cookie. If it still succeeds → vulnerable.
4. Try a forged page — build an auto-submitting form (Chapter 3) on a different origin, load it while logged in, and see if the action fires.
5. Test the token's strength — does the server accept an empty token? Another user's token? A token after it should have rotated?

The Broken-Defence Catalogue

These look protected but aren't — the patterns to hunt for in review:

The Hardening Checklist

Hands-On Exercises