SSRF and CSRF sound similar because both end with request forgery, but they affect different trust boundaries. Understanding that difference helps developers choose the right prevention controls.
Table of Contents
SSRF vs CSRF: Quick Comparison
| Aspect | SSRF | CSRF |
|---|---|---|
| Full form | Server-Side Request Forgery | Cross-Site Request Forgery |
| Abused trust | Server-side network trust | Browser session trust |
| Request comes from | The vulnerable server | The victim’s browser |
| Common impact | Accessing internal services, metadata, or backend-only resources | Unwanted state-changing actions by an authenticated user |
| Main defenses | Allowlisted destinations, egress filtering, URL validation, metadata protection | CSRF tokens, SameSite cookies, origin checks, re-authentication for sensitive actions |
What is SSRF?
Server-Side Request Forgery happens when an application lets user-controlled input influence a server-side request. The server may be able to reach internal hosts, private services, or cloud metadata endpoints that normal users cannot access directly.
A safe way to think about SSRF is: the application server becomes the request sender. That is why URL validation alone is not enough; network-level controls are also important.
What is CSRF?
Cross-Site Request Forgery happens when a malicious page or link causes a logged-in user’s browser to send a request to a trusted site. If the trusted site accepts the request only because the browser includes session cookies, an unwanted action may occur.
CSRF usually targets state-changing actions such as profile updates, email changes, transfers, or admin actions. Modern controls reduce the risk, but sensitive endpoints should still be designed carefully.
Simple Memory Rule
- SSRF: Server is tricked into sending the request.
- CSRF: Client browser is tricked into sending the request.
- XSS connection: Cross-site scripting can weaken browser-side protections, so XSS prevention also supports CSRF defense.
Prevention Checklists
SSRF Prevention
- Use strict allowlists for permitted URL destinations.
- Block private IP ranges, localhost, link-local, and metadata-service addresses where not needed.
- Apply network egress controls so app servers cannot freely reach internal services.
- Resolve and validate hostnames safely to reduce DNS rebinding risk.
- Do not return raw backend responses to users.
CSRF Prevention
- Use unpredictable CSRF tokens for state-changing requests.
- Set cookies with appropriate SameSite, Secure, and HttpOnly attributes.
- Validate Origin and Referer headers where practical.
- Require re-authentication or step-up verification for high-risk actions.
- Avoid using GET requests for state-changing actions.
Common Confusion
SSRF is not prevented by CSRF tokens because the browser is not the main problem. CSRF is not solved by blocking internal IP addresses because the server is not the request sender. Each vulnerability has a different trust boundary and therefore needs different controls.
FAQs
What is the simplest difference between SSRF and CSRF?
Which is more dangerous, SSRF or CSRF?
Does SameSite cookie protection prevent SSRF?
Can XSS bypass CSRF protections?
Summary
SSRF and CSRF are both request-forgery issues, but they are not interchangeable. SSRF focuses on server-side requests and internal reachability. CSRF focuses on browser sessions and unwanted authenticated actions. Good web security testing should check both separately.