Anatomy of an Attack

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