What is the difference between SSRF and CSRF?

How SSRF and CSRF differ in the trust boundary they abuse

SSRF and CSRF both weaponise trust, but they do it on opposite sides of the application boundary. SSRF turns a server into the requester, so the application’s network position and outbound reach become the problem. CSRF turns the victim’s browser into the requester, so the user’s authenticated session is the asset being abused. That difference determines where you validate input, where you enforce trust, and what “safe” looks like.

With SSRF, the core question is whether the server can be induced to fetch internal URLs, metadata endpoints, or otherwise privileged destinations. With CSRF, the core question is whether a browser can be tricked into sending a state-changing request that the target site will accept because the user is already signed in. The first is about server-side request authority; the second is about request legitimacy in a user session.

That distinction is why Web Application Attacks Guide is a natural reference point for both patterns, since it groups them with other request-level abuse cases where trust boundaries, parsing, and validation matter more than the headline payload.

Why SSRF is usually an infrastructure and data exposure problem

SSRF becomes dangerous when a backend can reach more than a normal browser can reach. The application may have access to internal services, cloud metadata, private APIs, or management interfaces that were never meant to be reachable from the public internet. Once the server is made to issue the request, the attacker often inherits whatever network adjacency and trust the server already has.

The practical failure mode is not just “bad URL input”. It is the combination of URL handling, redirect handling, DNS resolution, outbound egress, and service-to-service trust. A weak allowlist, permissive proxying, or a missed metadata-service control can turn SSRF into credential exposure, internal enumeration, or lateral movement inside the environment.

The strongest defensive pattern is to treat outbound requests as a security boundary, not a convenience feature. The SSRF Prevention Guide is directly relevant here because it covers URL validation, egress controls, and cloud metadata abuse, which are the exact controls that decide whether SSRF stops at request tampering or becomes a serious breach path.

Why CSRF is primarily an application session and authorization problem

CSRF depends on the browser automatically attaching credentials, such as cookies or other ambient session state, to a request that the user did not intend to make. The attacker does not need to read the response. They only need the target site to accept the forged request as if it came from the authenticated user.

That is why CSRF is less about network reach and more about request origin, intent, and action validation. If a state-changing endpoint trusts only the presence of a session cookie, it is vulnerable to abuse through cross-site form posts, image tags, auto-submitted forms, or similar browser behaviours. Strong anti-CSRF tokens, origin or referer checks where appropriate, and correct same-site cookie settings reduce that exposure.

CSRF tends to matter most on actions that change state without a separate user confirmation step, such as account changes, payment changes, privilege changes, or API actions that accept browser credentials implicitly. It is a design failure in how the application distinguishes legitimate user intent from ambient browser authentication.

How to tell them apart during review and testing

If the attack payload is trying to make the server call something on the attacker’s behalf, think SSRF. If the payload is trying to make the victim’s browser submit a request to a site where they are already logged in, think CSRF. That simple test usually separates the two, even when the practical exploit path involves both web inputs and authenticated sessions.

In testing, look at where the control sits. SSRF testing focuses on server-side fetch behaviour, redirect handling, DNS rebinding resistance, and access to internal ranges or metadata services. CSRF testing focuses on whether state-changing endpoints require explicit anti-csrf protection and whether the application trusts browser-originated requests too broadly.

Capital One breach 2019 is a useful SSRF reference because it shows how a server-side request flaw can become a cloud credential exposure problem when the backend reaches something sensitive that should never have been reachable from that path.

Risk and Threat Considerations

SSRF and CSRF both create trust-abuse risk, but the blast radius differs sharply. SSRF can expose internal services, metadata endpoints, or private network resources, while CSRF can trigger unwanted account or business actions under a victim’s authenticated session. In both cases, the attacker succeeds by making a trusted component do something it should not have done.

Failure mechanism: SSRF succeeds when server-side request handling is allowed to reach privileged destinations, and CSRF succeeds when a state-changing endpoint accepts browser-originated requests without proving user intent.

Impact: SSRF can lead to internal reconnaissance, secret exposure, or cloud credential theft; CSRF can cause unauthorized transactions, configuration changes, or account actions performed as the victim.

Practitioner Guidance

What to verify: For SSRF, verify that outbound requests are constrained by allowlists, network egress policy, and metadata-service protections. For CSRF, verify that every state-changing browser endpoint has a concrete anti-CSRF control and does not rely on session presence alone.

Decision rule: If the flaw allows the application to reach internal infrastructure, treat it as an SSRF-class issue and prioritise network reach reduction and secret exposure review. If the flaw lets a logged-in user trigger an unwanted action, treat it as a CSRF-class issue and prioritise request-origin validation and state-change protection.

Practitioner takeaway: SSRF is about stopping untrusted inputs from inheriting server reach, while CSRF is about stopping untrusted sites from inheriting user intent through the browser.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• What is the difference between SAST and DAST for security teams?
• What is the difference between CSRF protection and CORS hardening in this context?
• What is the difference between CORS and CSRF protection in Django applications?