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 |
SSRF is a server-side vulnerability. You're making the server send HTTP requests to places it shouldn't — internal APIs, cloud metadata endpoints, databases on the private network. The server is your proxy.
CSRF is a client-side attack. You're making the victim's browser send requests they didn't intend — using their cookies and session. The victim is your proxy.
The name. That's it. "Request forgery" appears in both, and if you're learning appsec, they sound like the same thing. They're not. SSRF exploits the server's trust in itself. CSRF exploits the browser's trust in the user's session.
SSRF tends to be higher severity because it can reach internal infrastructure — the Capital One breach was an SSRF that accessed AWS metadata credentials. CSRF impact depends entirely on what the forged request does. A CSRF that changes an email address can lead to account takeover. A CSRF that changes a display name is low severity.