SSRF vs CSRF: Who Is Forged, What Breaks and How to Defend

Server-side request forgery (SSRF) and cross-site request forgery (CSRF) share a word and an acronym pattern, and teams regularly fix the wrong one: adding CSRF tokens to a URL-fetching endpoint does nothing against SSRF, and egress firewalls do nothing against CSRF. Both abuse a trusted party into sending a request the attacker could not send directly, but the forged party is different: in SSRF it is your server, in CSRF it is your user's browser. That one difference changes the impact, the controls, the owners and how you test. This guide compares the two side by side, with threat models, architecture in words, failure modes, control mappings, testing and a worked scenario. It is for application security engineers, developers, cloud engineers and assessors, and it contains no payloads or bypass techniques. For the full treatment of each, see the SSRF Prevention Guide and the CSRF Prevention Guide.

Key takeaways

• The forged party differs. SSRF makes your server send a request with its network position and credentials; CSRF makes a signed-in user's browser send a request with that user's cookies.
• The impact differs. SSRF typically reaches internal services and the cloud instance metadata service, where workload credentials live; CSRF performs actions as the victim user, limited to what that user may do.
• The controls do not transfer. SSRF is stopped by destination allowlists, connection-time IP validation, disabled redirects, egress filtering and hardened metadata services; CSRF by framework tokens, Fetch Metadata checks, origin verification and SameSite cookies.
• Different teams own the fix. SSRF defence spans developers, platform and cloud teams because the network and metadata layers matter; CSRF defence sits almost entirely in the web framework and session design.
• Test each on its own terms. SSRF testing needs out-of-band callbacks and cloud-aware scoping; CSRF testing checks every state-changing endpoint for a verified anti-forgery signal, including APIs and login.

The short answer

MITRE CWE-918 describes SSRF as a server that receives a URL or similar request from an upstream component and retrieves its contents without sufficiently ensuring the request goes to the expected destination; it is a child of CWE-441, the unintended proxy. CWE-352 describes CSRF as an application that does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent it; alternate names include session riding and XSRF. Both CWEs appear in the 2025 CWE Top 25. OWASP lists SSRF as API7:2023 in the API Security Top 10, and names both CWE-918 and CWE-352 among the notable CWEs for A01:2025 Broken Access Control. CAPEC catalogues them as CAPEC-664 Server Side Request Forgery and CAPEC-62 Cross Site Request Forgery.

A quick test: ask which machine sends the forged request. If it is a server you run, it is SSRF. If it is a user's browser carrying that user's session, it is CSRF.

Side-by-side comparison

SSRF in depth: threat model, architecture and impact

Threat model: the attacker is outside the network and wants to reach what the server can reach. Entry points are features that make outbound requests on a user's behalf: URL previews, webhooks, image and document import by URL, PDF and HTML renderers, integrations that call a user-supplied endpoint, and increasingly AI agent tools that browse or fetch. The payoff in cloud estates is usually the instance metadata service at the link-local address 169.254.169.254, which issues temporary credentials for the workload's role. ATT&CK tracks the credential step as T1552.005 Cloud Instance Metadata API, typically after initial access through T1190 Exploit Public-Facing Application.

Architecture in words: the vulnerable component takes a destination from input, resolves it, connects from inside the trust boundary, and returns or acts on the response. The flaw sits in the gap between what the code validated (a string) and where the connection actually went (an IP address after DNS resolution, redirects and parser interpretation). OWASP's SSRF cheat sheet warns that domain allowlisting alone does not prevent DNS rebinding and that redirects can bypass input validation.

Why the metadata service matters: cloud providers have added request requirements that blunt simple SSRF. AWS IMDSv2 requires a PUT to obtain a session token with a TTL of 1 second to 6 hours, rejects token PUT requests that carry an X-Forwarded-For header, and defaults the PUT response hop limit to 1; setting HttpTokens to required makes IMDSv1 calls fail. Azure IMDS requires the header Metadata: true and rejects requests containing X-Forwarded-For. Google Compute Engine requires Metadata-Flavor: Google and rejects forwarded requests. These raise the bar for SSRF that cannot set headers or methods, but a full-control SSRF can still meet them, so they complement, not replace, application and network controls. See the Cloud Instance Metadata Services Compared Guide and the EC2 Instance Metadata Service Hardening Guide.

Real-world illustration: in the Capital One breach, a misconfigured web application firewall in AWS was widely reported to have been abused through SSRF against the metadata service, yielding credentials for a role that could read far more storage than a firewall needs. The lesson cuts across both layers: the request forgery opened the door, and the over-scoped workload role set the size of the breach.

CSRF in depth: threat model, architecture and impact

Threat model: the attacker cannot steal the victim's session but can get the victim's browser to send a request. The victim is signed in to the target application; they visit a page, open an email or load content the attacker controls; that content causes the browser to submit a request to the target; the browser attaches the target's cookies according to their SameSite setting; and a server that checks only the cookie performs the action. CWE-352 notes that the scope of CSRF is limited only by the victim's privileges.

Architecture in words: the flaw is authentication by ambient credential alone. Any endpoint that changes state and accepts a request authenticated only by a cookie or HTTP authentication, with no proof that the request came from the application's own pages, is exposed. Variants include login CSRF (signing the victim into the attacker's account, so later activity is captured), client-side CSRF (attacker-controlled input such as a URL fragment drives the application's own JavaScript to send a forged same-origin request, which tokens and SameSite do not stop), and CSRF against OAuth clients, where ASVS V10.2.1 requires PKCE or a checked state parameter.

Browser changes: SameSite cookies and Fetch Metadata headers have shrunk the attack surface. MDN describes Sec-Fetch-Site as a forbidden request header that scripts cannot set, with values same-origin, same-site, cross-site and none, and lists it as Baseline widely available since March 2023. OWASP's CSRF cheat sheet treats SameSite as defence in depth rather than a fix, because Lax still sends cookies on top-level GET navigations and same-site is scoped to the registrable domain, so a compromised sibling subdomain counts as same-site. See the Cookie Security Guide.

Controls per attack

Two details matter most. For SSRF, validation must happen at connection time on the resolved address, not only on the input string, because a second unchecked DNS lookup can undo the check. For CSRF, OWASP's order is: use the framework's built-in protection first; otherwise use tokens; use Fetch Metadata as a strong primary signal only with an Origin fallback for clients that omit it; and layer SameSite on top. For how CORS interacts with custom-header defences, see the CORS Misconfiguration Guide.

Testing each

SSRF testing

• Find the sinks: inventory every feature that makes an outbound request from user influence, including webhooks, importers, renderers and AI agent tools. Code review and static analysis (OWASP suggests tools such as Semgrep) find sinks that black-box scanning misses.
• Use out-of-band detection: blind SSRF returns nothing in the response, so authorised testers use a controlled callback endpoint to confirm the server made a request.
• Scope cloud reach carefully: rules of engagement should say whether testers may confirm metadata reachability and must never use any credential obtained. Report reachability, not harvested secrets.
• Test the controls, not just the bug: confirm IMDSv2 is enforced, egress rules block unexpected destinations, and redirects are refused.

CSRF testing

• Enumerate state-changing endpoints: forms, JSON APIs, file uploads, WebSocket handshakes (ASVS V4.4.2 requires an Origin check) and the login form.
• Check the anti-forgery signal: for each endpoint, confirm the server rejects a request without a valid token, with a cross-site Fetch Metadata value, or with an untrusted Origin, and does not accept a missing Origin or Origin: null as proof of same origin.
• Review exemptions: most real CSRF failures are disabled middleware or exempted routes, so grep for framework exemption decorators and settings.
• Check cookie scope and CORS: SameSite value per cookie purpose (ASVS V3.3.2) and no wildcard or reflected origins that would let a custom-header defence be bypassed.

See the OWASP WSTG Guide for test case structure and SAST vs DAST for which tooling finds which class.

Common failure patterns

• Applying the wrong fix: a URL import endpoint gets a CSRF token after a pen test finding labelled "request forgery". The server still fetches internal addresses. Name the class precisely in findings.
• Validating the string, connecting elsewhere: an SSRF allowlist checks the hostname, but the HTTP client re-resolves DNS or follows a redirect to an internal address.
• Relying on IMDSv2 alone: metadata hardening is treated as the SSRF fix while internal admin services, databases and container credential endpoints stay reachable from the web tier.
• Trusting SameSite alone: CSRF tokens are removed because browsers default to Lax, leaving GET-based state changes and sibling subdomains exposed.
• Exempting APIs from CSRF checks: cookie-authenticated JSON endpoints are exempted on the assumption that only scripts call them, while CORS reflects any origin.
• Over-scoped workload roles: the SSRF is minor, but the role behind the metadata service can read every bucket, as the Capital One case showed.

Decision guidance: which to prioritise

1. Cloud-hosted service with URL-fetching features: SSRF first. A single SSRF can yield workload credentials, so enforce IMDSv2 or equivalent across the estate, then add egress filtering, then fix the code paths.
2. Browser application with cookie sessions: CSRF first. Confirm framework protection is on everywhere, then add Fetch Metadata checks and review SameSite settings.
3. Token-authenticated APIs (bearer tokens in an Authorization header, no cookies): CSRF largely does not apply because the browser does not attach the token automatically; SSRF still applies wherever the API fetches URLs.
4. AI agents and integrations: treat agent fetch and browse tools as SSRF sinks with egress controls. See the Agent Egress Control and Network Isolation Guide.
5. Small versus large teams: small teams get most value from platform defaults (framework CSRF on, IMDSv2 required by default, a deny-by-default egress proxy). Large organisations should standardise a shared hardened outbound HTTP client library and a CSRF middleware baseline, and test them centrally.

Worked scenario: one finding, two classes

A SaaS product lets customers set a webhook URL in account settings. A pen test reports "request forgery in webhook settings".

• The CSRF half: the settings form changes the webhook URL using only the session cookie, so a malicious page could silently change a signed-in admin's webhook to an attacker-controlled endpoint and receive future event data. Fix: turn the framework's CSRF protection back on for the route (it had been exempted during an API migration) and add a Fetch Metadata check.
• The SSRF half: the webhook dispatcher sends events to whatever URL is configured, from a subnet that can reach internal services and the metadata service. Fix: validate destinations at connection time against public address space only, disable redirects, route dispatch through an egress proxy, require IMDSv2 on the dispatcher hosts and cut the dispatcher role down to the queue it reads.
• Outcome: two tickets to two owners (web framework and platform), each with its own retest, instead of one ticket that fixes half the problem. See the Webhook Secrets Security Guide for signing outbound webhooks.

Where identity fits

SSRF is often a non-human identity incident in disguise: the forged request matters because the server holds a workload identity whose credentials the metadata service hands to any local caller. Scope workload roles tightly, prefer short-lived credentials, and alert on use of instance credentials from outside the expected network. CSRF is a human session problem: the defence is proving intent per request, and step-up for sensitive actions.

Detection and measurement

• SSRF signals: egress proxy denials from application tiers; connections from web workloads to link-local, loopback or RFC 1918 addresses they never normally reach; cloud audit logs showing instance role credentials used from an unexpected source.
• CSRF signals: spikes in rejected anti-forgery checks; state-changing requests with a cross-site Sec-Fetch-Site value or a missing Origin; account setting changes immediately followed by unusual activity.
• Metric: metadata hardening coverage: share of compute instances with IMDSv2 required or equivalent controls.
• Metric: egress default-deny coverage: share of internet-facing workloads behind an allowlisting egress control.
• Metric: CSRF exemption count: number of routes exempted from framework CSRF protection, each with a documented reason, trending down.
• Metric: time to remediate: median days to fix SSRF and CSRF findings, reported separately.

Framework mapping

Practitioner checklist

• Label findings precisely as SSRF or CSRF and route them to the right owner.
• Inventory every server-side URL fetch, including webhooks, importers, renderers and agent tools.
• Build outbound requests server-side, validate resolved IPs at connection time and disable redirects.
• Require IMDSv2 (or the provider equivalent) and scope workload roles to least privilege.
• Put internet-facing workloads behind default-deny egress.
• Keep framework CSRF protection on, track every exemption, and never change state on GET.
• Add Fetch Metadata checks with an Origin fallback, and set SameSite per cookie purpose.
• Protect OAuth client flows with PKCE or a checked state parameter.
• Test SSRF with out-of-band callbacks under clear rules of engagement, and CSRF on every state-changing endpoint including login.

Standards and references

• MITRE CWE: CWE-918 Server-Side Request Forgery (SSRF)
• MITRE CWE: CWE-352 Cross-Site Request Forgery (CSRF)
• OWASP: Server Side Request Forgery Prevention Cheat Sheet
• OWASP: Cross-Site Request Forgery Prevention Cheat Sheet
• OWASP: Application Security Verification Standard 5.0
• OWASP: API Security Top 10 2023
• AWS: Use the Instance Metadata Service to access instance metadata
• MDN: Sec-Fetch-Site

Related NHI Mgmt Group resources: Web Application Attacks Guide, Cloud Egress Filtering, Security Headers Guide, Application Security Guide.