Join our Newsletter — 33% off our NHI Course

SSRF Attack

An SSRF attack tricks a server into sending requests to internal or external systems on the attacker’s behalf. In practice, the attacker supplies a URL or reference that backend code fetches, potentially exposing cloud metadata, internal APIs, secrets, or network-only services and bypassing perimeter controls.

How SSRF Attacks Work

Server-side request forgery turns a trusted backend into the requester, so the server becomes the one making the network call. That matters because application allowlists, user-interface checks, and perimeter filters often trust backend traffic that the attacker can now steer.

SSRF is dangerous in environments where the server can reach internal-only hosts, metadata endpoints, admin interfaces, or service-to-service APIs that are not exposed to the public internet. A single successful payload can shift the attack from input manipulation into internal network reachability and trust abuse.

Blind SSRF is especially important to understand because the attacker may not see the full response, yet still uses timing, error behaviour, or side effects to probe internal services. That makes the attack useful for recon, port probing, and chained exploitation even when the response body is hidden.

The most serious outcomes usually appear when SSRF reaches cloud metadata services, internal control planes, or privileged management endpoints. In those cases, the request itself becomes a bridge into a network zone the attacker could not normally touch.

Why SSRF Becomes a Trust-Boundary Problem

SSRF is not just “a bad URL fetch.” It is a trust-boundary failure where the application implicitly vouches for a destination that the attacker controls. Once the backend is allowed to fetch arbitrary or weakly constrained targets, the server can be used as a proxy into systems that were meant to stay private.

That proxy behaviour is what makes SSRF so effective against cloud and hybrid environments. Backend services often have richer network access than end users, and they may sit close to internal APIs, instance metadata, container networks, or orchestration endpoints.

When the backend can reach internal resources, SSRF can bypass segmentation assumptions. A control that blocks direct external access to a service does not help if the attacker can convince a reachable server to make the request on their behalf.

In practice, SSRF often appears alongside URL parsing flaws, redirect handling mistakes, weak scheme validation, or overly broad fetch features. The issue is not only whether a URL is accepted, but whether the application truly constrains where the server may connect.

Common Exposure Paths and Chaining Scenarios

One common exposure path is cloud metadata access. If a server can query an instance metadata endpoint, the attacker may be able to retrieve information that helps them pivot deeper into the environment or impersonate the workload’s effective permissions.

Another common path is internal API access. SSRF can reach services that were assumed to be isolated behind firewalls, load balancers, or private DNS, including administrative consoles, health endpoints, and internal microservice interfaces.

SSRF can also be used for port scanning, service discovery, and blind enumeration. Even when data is not directly returned, response timing and error behaviour can reveal whether a host or port is alive and what kind of service sits behind it.

In more complex cases, SSRF becomes a stepping stone rather than the final objective. An attacker may use it to locate a privileged service, capture temporary credentials, or reach a second weakness that was never intended to be internet-facing.

Detection, Containment, and Safe Remediation

Defenders should look for unusual outbound requests from application servers, especially requests to metadata IPs, internal ranges, localhost, link-local addresses, or hosts that are not part of the application’s normal dependency set. Proxy logs, DNS logs, and egress telemetry are often the best evidence sources.

Containment usually starts with restricting outbound network reachability so servers can only talk to destinations they genuinely need. Safe remediations also include strict URL allowlisting, server-side resolution checks, redirect handling controls, and explicit blocking of sensitive address spaces and schemes.

Where a fix cannot be deployed immediately, compensating controls should reduce the blast radius of any successful request. That usually means tightening egress policy, isolating sensitive internal services, and reducing the permissions attached to any service credentials that the server can reach.

Because SSRF often creates a post-exploitation path, remediation should be paired with compromise review. If the vulnerable service could contact metadata or privileged internal endpoints, investigate whether tokens, secrets, or internal data were accessed before the issue was closed.

Risk and Threat Considerations

SSRF is risky because it turns ordinary backend functionality into a route around network trust boundaries. The biggest concern is not just a single request, but the chance that the attacker can pivot from an externally reachable app into private services, cloud metadata, or management interfaces.

Failure mechanism: The application accepts attacker-influenced destinations and lets the server perform requests with network reach and privileges the attacker does not have. That can expose internal-only services, metadata, or other sensitive resources that were assumed to be unreachable.

Impact: Successful exploitation can lead to internal recon, secret exposure, credential harvesting, lateral movement, or compromise of downstream services that trust the server’s network location or identity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP ASVS V4 — API and Web Service SSRF is a server-side web request abuse issue in API and web service handling.
Recommendation — Validate and constrain server-side URL fetching and outbound request handling.
CIS Controls v8 CIS-12 — Network Infrastructure Management SSRF defense depends on controlling server egress paths and internal reachability.
Recommendation — Restrict outbound network paths so servers can reach only approved destinations.
NIST SP 800-53 Rev 5 SC-7 — Boundary Protection SSRF exploits weak trust boundaries between public input and private network access.
CM-7 — Least Functionality Limiting unnecessary outbound capabilities reduces the attack surface for SSRF abuse.
Recommendation — Enforce boundary controls that limit server-initiated connections to approved targets. Remove unnecessary URL fetch features and disable nonessential outbound access.
OWASP API Security Top 10 API7 — Server Side Request Forgery This is the canonical API security risk for attacker-driven server requests.
Recommendation — Identify and block server-side fetch paths that can be redirected to attacker-chosen targets.

Practitioner Guidance

What to watch for: Treat any feature that fetches URLs, imports webhooks, previews content, or resolves remote resources as a security-sensitive control point. The important question is not whether the input looks like a URL, but whether the backend can be induced to contact something the user should never be able to reach.

Governance implication: Ownership should sit with the team that controls outbound reachability and backend fetch behaviour, not only with the application feature owner. SSRF prevention is strongest when application validation, network egress policy, and cloud metadata protections are managed together rather than as separate concerns.