Both have "request forgery" in the name, but they work in completely different ways.
| SSRF | CSRF | |
|---|---|---|
| Full name | Server-Side Request Forgery | Cross-Site Request Forgery |
| Who makes the request? | The server | The victim's browser |
| Attacker's goal | Access internal services, cloud metadata, or private networks | Perform actions as the victim (transfer funds, change email) |
| Attacker sees response? | Often yes (or via OOB) | No — the attacker never sees the response |
| Requires authentication? | No — exploits the server's network position | Yes — relies on the victim's existing session |
| Typical targets | Webhook URLs, PDF generators, image fetchers | State-changing forms and API endpoints |
| Key defense | Allow-list outbound URLs, block internal IPs | CSRF tokens, SameSite cookies |
| OWASP Top 10 | A10:2021 (new entry) | Was in Top 10 through 2017, now under A01 |
The names differ by one letter and the vulnerabilities have almost nothing in common. In CSRF the victim's browser is tricked into sending a request the user didn't intend. In SSRF the server is tricked into sending a request the developer didn't intend. Different actor, different target, different defenses.
Ask who makes the request. That single question resolves nearly every case. If the attack requires a logged-in victim to visit a page, and the damage is done with that victim's cookies, it's CSRF. If the attack works with no victim at all — you send a URL, the server fetches it — it's SSRF.
Ask what the attacker gains. CSRF gets you actions, not data: the attacker can make the victim perform a state change, but cannot read the response, because the same-origin policy prevents it. That's why CSRF findings are about transfers, password changes and setting modifications rather than data theft. SSRF gets you reach: the response often comes back, and even when it doesn't, you've obtained the ability to make requests from inside a network you're not on.
Ask what's being trusted. CSRF exists because the browser automatically attaches credentials to cross-origin requests — the server trusts the cookie to mean intent. SSRF exists because internal services trust the network position of the caller — they're unauthenticated because they were assumed unreachable. In both cases the vulnerability is an assumption, not a parser bug.
A SaaS product has a settings page where an administrator can set a webhook URL for event notifications, and a billing page where they can change the plan.
The CSRF. The plan-change endpoint accepts a POST with no anti-CSRF token, and the session cookie is SameSite=None because the product embeds in a partner iframe. An attacker hosts a page that auto-submits a form to that endpoint. An administrator who visits it while logged in downgrades their own plan. The attacker never sees the response and doesn't need to — the state change is the payoff. The fix is a per-session token bound to the form, or tightening the cookie policy and routing the iframe integration differently.
The SSRF. The webhook field accepts any URL and the server validates it by making a test request. The attacker sets it to http://169.254.169.254/latest/meta-data/iam/security-credentials/ and reads the test response in the UI, obtaining the role credentials the instance runs under. No victim is involved; the attacker is the one doing it, to their own account. The fix is resolving the hostname and rejecting private and link-local addresses immediately before connecting, refusing redirects, and requiring IMDSv2.
Same feature set, same application, and no single control addresses both.
Against CSRF: synchronizer tokens bound to the session, SameSite cookie attributes (which are now the default and have removed most of this class), origin and referer validation, and requiring a custom header that a simple cross-origin form cannot set. Note that none of these involve inspecting a URL.
Against SSRF: validate the resolved IP address immediately before connecting rather than validating the URL string, refuse to follow redirects across a trust boundary, egress-filter the service so it cannot reach internal ranges, and — most durably — require authentication on internal services instead of relying on their being unreachable. Note that none of these involve tokens or cookies.
The one thing they share is a failure mode: both are frequently "fixed" by a blocklist, and both bypass literatures are largely catalogues of how parsers disagree. For CSRF it's the referer check that passes on a subdomain; for SSRF it's DNS rebinding, alternate IP encodings and redirect chains.
Triage. A report titled "CSRF on the webhook endpoint" that actually describes fetching cloud metadata gets routed to whoever owns session handling, who correctly observes that the token validation is fine, and closes it. The reverse happens too. If you're writing the report, describing who sends the request is worth more than naming the class.
There is also a genuine chained case worth knowing: CSRF into SSRF. If the webhook configuration endpoint lacks CSRF protection, an attacker can make an administrator set a webhook pointing at internal infrastructure — combining both, with the victim supplying the privilege and the server supplying the network position. Full collections for each are at SSRF and CSRF.
No, and the analogy misleads more than it helps. CSRF abuses a browser's automatic credential attachment and cannot read responses. SSRF abuses a server's network position and usually can. They share no defenses.
SSRF, generally, in cloud environments — it routinely reaches credentials and internal services, and needs no victim. CSRF severity depends entirely on what the forged action does, and SameSite defaults have made it much rarer.
They removed most of it. What remains is GET-triggered state changes, cookies explicitly set to SameSite=None, non-cookie authentication such as bearer tokens or Basic auth, and the brief window some browsers allow for newly-issued cookies.
No. A CSRF token establishes that the request came from your own application; it says nothing about where the server will then connect. The attacker in an SSRF is usually an authenticated legitimate user with a valid token.
Point it at a server you control and show the inbound connection with its source address and user agent. That demonstrates the primitive and where it originates without reaching into infrastructure you aren't authorized to touch.