SSRF Explained: Server-Side Request Forgery and Cloud Risk

Server-side request forgery is the vulnerability that turned cloud misconfiguration into a headline risk. The application is tricked into fetching a URL chosen by the attacker, and because that request originates from inside your infrastructure, it inherits trust that an external request never would.

SSRF Explained: When Your Server Becomes the Attacker

How SSRF works

Any feature that fetches a URL supplied by a user is a candidate: webhook configuration, URL preview generation, PDF and image rendering, file import from a link, or an integration that calls a customer-provided endpoint.

The attacker supplies a URL pointing not at the public internet but at something only your server can reach — an internal admin panel, a database HTTP interface, a container orchestrator API, or a cloud metadata service. Your server makes the request and, in many implementations, returns the response.

Why cloud makes it critical

Major cloud platforms expose an instance metadata service on a link-local address that returns configuration and, in some configurations, temporary credentials for the instance role.

If an attacker can make your instance request that endpoint and reflect the result, they may obtain credentials that let them act as your workload. This is why SSRF is frequently the first link in a chain that ends in large-scale cloud data exposure. Modern instance metadata services support a session-oriented mode that substantially mitigates this, and enforcing it is one of the highest-value cloud hardening steps available.

Cloud metadata endpoints are the classic SSRF target

Blind SSRF still matters

Sometimes the response is never shown to the attacker. That is blind SSRF, and it is still dangerous.

An attacker can confirm reachability through timing differences or by pointing the request at infrastructure they control and watching for the DNS lookup or HTTP callback. From there they can map your internal network, and any internal endpoint that performs an action on a plain GET request can be triggered directly.

Why naive defences fail

Blocking "localhost" and 127.0.0.1 — trivially bypassed with alternative encodings, alternative loopback addresses, or a hostname that simply resolves to a loopback address.
Validating the URL once — DNS can return a different address on the second lookup, so a check performed before the request may not describe the address actually contacted.
Following redirects — a permitted external URL can redirect to an internal one, moving the request past your check.
Parsing URLs by hand — credentials in the authority section, unusual schemes and encoding tricks routinely defeat homemade parsers.

Allow-lists beat blocklists for outbound requests

Defending properly

Allow-list destinations. Permit only the specific hosts the feature genuinely needs, rather than trying to enumerate everything that is forbidden.
Resolve the hostname, validate the resulting IP address against private and link-local ranges, and connect to that validated address to avoid a re-resolution gap.
Disable redirect following, or re-validate the destination on every redirect hop.
Restrict schemes to http and https, blocking file, gopher, ftp and similar.
Enforce the session-oriented mode of your cloud metadata service and remove unnecessary permissions from instance roles.
Isolate the fetching component at the network layer with egress filtering, so a bypass still cannot reach sensitive internal ranges.
Do not return the raw upstream response to the user where it can be avoided.

Related from TechBiz Security

Sources & further reading

Frequently asked questions

What is SSRF in simple terms?

Server-side request forgery tricks your application into making an HTTP request to a destination the attacker chooses. Because the request comes from inside your infrastructure it can reach internal services that are not exposed to the internet.

Why is SSRF considered so severe in cloud environments?

Cloud instances expose a metadata service that can return configuration and temporary credentials for the instance role. If SSRF reaches that endpoint and the response is reflected, an attacker may gain the workload's own permissions and pivot into cloud resources.

Is blind SSRF actually exploitable?

Yes. Even without seeing the response, an attacker can map internal infrastructure using timing and out-of-band callbacks, and can trigger any internal endpoint that performs an action on a simple GET request.

Is blocking internal IP addresses enough?

No. Blocklists are bypassed with alternative encodings, DNS records pointing at internal addresses, and redirects from permitted hosts. An allow-list of required destinations plus egress filtering is far more reliable.

SSRF Explained: When Your Server Becomes the Attacker