CSRF vs SSRF: What's the Difference?
CSRF and SSRF sound almost identical and both involve a "forged request," which is why they are so often confused. The difference is who is tricked into making the request. In CSRF (Cross-Site Request Forgery) the attacker abuses the victim's browser to act on the user's behalf. In SSRF (Server-Side Request Forgery) the attacker abuses the server to act on the attacker's behalf. One points outward through a user; the other points inward through your backend.
What is CSRF?
Cross-Site Request Forgery tricks a logged-in user's browser into sending a state-changing request they never intended — transferring money, changing an email, deleting a resource. It works because browsers automatically attach the victim's session cookies to any request to a site, so a hidden form or image on an attacker's page can fire an authenticated action. CSRF abuses the trust a website places in the user's browser.
What is SSRF?
Server-Side Request Forgery tricks your server into making an HTTP request to a destination the attacker controls. If a feature fetches a URL the user supplies — a webhook, an image importer, a PDF renderer — and does not validate it, the attacker can point it at internal services or the cloud metadata endpoint (169.254.169.254) to steal credentials. SSRF abuses the trust and network position of the server.
CSRF vs SSRF at a glance
| CSRF | SSRF | |
|---|---|---|
| Who makes the forged request | The victim's browser | The vulnerable server |
| Trust abused | Site's trust in the user's browser (cookies) | Server's trust and internal network access |
| Typical target | A state-changing action in the app | Internal services, cloud metadata, other hosts |
| Who benefits | Action runs as the victim | Request runs as the server, for the attacker |
| Main defence | Anti-CSRF tokens, SameSite cookies, Origin checks | Allowlist destinations, block internal IP ranges |
Why they get confused
Both are "request forgery" and both exploit an application making a request it should not. But the direction is opposite: CSRF sends a request from the user into your app, riding their session; SSRF sends a request from your app out to somewhere else, riding your server's access. Get the direction right and the two are easy to tell apart.
How to defend against each
- CSRF: issue an unpredictable anti-CSRF token on state-changing requests, set cookies to
SameSite=LaxorStrict, and verify theOrigin/Refererheader. Full detail in the CSRF guide. - SSRF: validate and allowlist the destinations your server may fetch, block requests to private and link-local ranges, and disable unused URL schemes. Full detail in the SSRF guide.
Related guides
Read the dedicated deep-dives on CSRF and SSRF, and scan your own app for these and other issues with the free website vulnerability scanner.
Frequently asked questions
Is SSRF more dangerous than CSRF?
Often, yes. SSRF can reach internal systems and cloud metadata to steal credentials, potentially leading to full compromise, while CSRF is limited to actions the victim user could already perform. Both are serious and appear in the OWASP Top 10.
Can the same endpoint be vulnerable to both?
They target different layers, so a single flaw is usually one or the other. An app can of course have separate CSRF and SSRF vulnerabilities in different features.
What is the simplest way to remember the difference?
CSRF = the client (browser) is tricked into sending a request. SSRF = the server is tricked into sending a request. Match the first letter to who makes the call.