SSRF vs CSRF: Key Differences, Examples and Prevention

SSRF vs CSRF, also searched as CSRF vs SSRF, compares two different request forgery risks. SSRF abuses server-side request trust, while CSRF abuses a logged-in user’s browser session. This guide explains the difference, examples, impact, and safe prevention controls.

SSRF vs CSRF: Quick Comparison

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.

Safe Review Checklist for Developers

Use this checklist during defensive code review or application design:

• List every feature that makes server-side outbound requests.
• Restrict outbound destinations with allowlists and network egress rules.
• Protect cloud metadata and internal-only services from application reachability.
• Use CSRF tokens for state-changing browser requests.
• Set cookies with appropriate SameSite, Secure, and HttpOnly attributes.
• Validate Origin or Referer headers where practical.
• Require step-up verification for sensitive actions such as email, password, payout, or role changes.
• Keep XSS prevention strong because XSS can weaken CSRF protections.

When to Worry About SSRF vs CSRF

Worry about SSRF when an application fetches URLs, imports remote files, generates previews, calls webhooks, or connects to user-supplied endpoints. Worry about CSRF when a logged-in user can trigger state-changing actions through browser requests. Many applications need both reviews because the vulnerable feature and trust boundary are different.

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.