SSRF: Making the API Attack Its Own Network

Server-Side Request Forgery turns your own API into an attacker's proxy. Any endpoint that takes a URL or hostname and fetches it — to import an image, render a webhook, preview a link, or pull a remote document — can be tricked into requesting a resource the attacker chooses. Because the request originates from your server, it arrives with your server's network position and trust, reaching places the attacker never could directly.

The premise is a feature almost every API has: "give me a URL and I'll fetch it." Profile-picture import, document conversion, webhook delivery, URL preview — all take a location and retrieve it server-side. SSRF is the attacker supplying a location that points inward: at internal services, at localhost, or at the cloud metadata endpoint. The server, trusting the input, makes the call and often hands the response straight back.

The cloud metadata prize

In cloud environments SSRF is especially dangerous because of the instance metadata service, reachable at a fixed link-local address from inside the workload. Left unprotected, it can return temporary credentials for the instance's role. An SSRF that reaches it can exfiltrate keys that grant access to storage, databases, and more — escalating a single fetch feature into a full cloud compromise. This is the pattern behind some of the most serious cloud breaches on record.

Modern SSRF is rarely a naive open fetch. Attackers defeat weak filters with redirects (a permitted URL that 302s to an internal one), DNS rebinding (a hostname that resolves to a safe address on validation and an internal one on fetch), alternate IP encodings, and blind variants where the response never returns but timing or out-of-band callbacks confirm the request landed.

Containing the fetch

• Allow-list destinations, don't block-list them. Permit only the specific schemes, hosts, and ports the feature legitimately needs; deny everything else. Block-lists of internal ranges are endlessly bypassable.
• Validate after DNS resolution, and pin it. Resolve the hostname, check the resulting IP against the allow-list, and fetch that same address — closing the rebinding and redirect gaps between check and use.
• Disable redirects, or re-validate each hop. A safe first URL must not be allowed to bounce the request to an internal target.
• Protect cloud metadata. Require the hardened, token-based metadata mode and give the workload the least IAM privilege it can function with, so a leaked credential is worth as little as possible.
• Isolate the fetcher and don't reflect raw responses. Run outbound fetches from a segmented network with no route to sensitive internal services, and avoid returning fetched content verbatim to the caller.

SSRF is a reminder that an API's trust boundary is not just who calls it but what it, in turn, calls. Every outbound request an API can be steered to make is part of its attack surface — and the ones that matter are easy to lose track of, buried in an integration a previous team wired up. You cannot lock down the fetches you don't know your API is capable of making.