SSRF: The Complete Practical Guide to Server-Side Request Forgery

Server-Side Request Forgery is when an application can be talked into making a request to a destination you choose, and that request goes out from the server instead of from you. That one shift of origin is the whole danger: the server's request carries the server's network reachability, its trust, and often its cloud identity, so it reaches places you never could directly, like 127.0.0.1, an internal admin panel, or the cloud metadata service. SSRF earned its own spot on the OWASP Top 10 once everything moved to cloud and microservices, because a feature as innocent as "fetch this image URL" became a doorway into the internal network. Want to feel it rather than read about it? Sign up free and try it on a live target.

What is SSRF?

Plenty of apps make outbound requests on your behalf. You paste a link and the server fetches it to build a preview. You give a webhook URL and the server calls it. You import a profile picture from a URL and the server downloads it. In each case the app takes a destination from you and has the server go get it.

SSRF is what happens when you control that destination and the app does not properly restrict where it can point. You are the attacker, but the request is made by the server, so it is the confused deputy: it has access you do not, and you are borrowing it. The one-sentence model: you choose the URL, the server makes the request, and the server's privileges come along for the ride.

Where SSRF hides

Look for any feature that takes a URL, a hostname, or anything that becomes one:

• Webhooks and callback URLs.
• Link previews and URL unfurlers.
• PDF and screenshot generators that render a page you supply.
• Image, avatar, and file importers ("import from URL").
• Document parsers that follow references (XML external entities, SVG, remote stylesheets).
• SSO and OIDC flows that fetch a metadata or JWKS URL.
• Any server-side HTTP client fed a value you can influence, including deep inside a JSON body.

If the server fetches something and you can steer where, you have a candidate.

Why it is dangerous

The payoff is not the fetch itself, it is where the fetch lands. A request made from inside the perimeter:

• Reaches internal-only services the firewall would never let you hit directly: admin panels, databases, message queues, metadata endpoints.
• Inherits ambient cloud credentials. The server often runs as a cloud role with real permissions, and the metadata service will hand those credentials to anything that asks from on-box.
• Maps the internal network. Timing and error differences let you port-scan and discover hosts from the outside.
• Becomes a launchpad. With the right protocol tricks, an SSRF can send crafted bytes to an internal service and turn a read primitive into remote code execution.

That range, from "fetch an internal page" to "own the cloud account," is why SSRF sits high on the server-side checklist.

How to find SSRF

The method is consistent:

• Find the URL-shaped input (obvious ones like url=, and non-obvious ones buried in JSON, headers, or import features).
• Point it at a server you control and watch for the inbound request. If it arrives, the app fetches attacker-chosen destinations.
• Then point it somewhere interesting: http://127.0.0.1/, an internal hostname, the metadata IP. Read the response if it comes back, or infer from status codes and timing if it does not.

Start with basic SSRF, and keep the cheat sheet open for the probes and targets worth trying first.

The types of SSRF

How you exploit it depends on whether the app shows you anything.

• In-band returns the fetched response in the page, so you read internal content directly. This is basic SSRF.
• Blind returns nothing useful, so you prove the request happened out-of-band and infer the rest from timing and side effects. This is blind SSRF, and blind is still dangerous because it can reach the metadata service even when you cannot see the body.

Reaching internal services

The server sits behind the firewall, so from its vantage point loopback and private ranges are wide open. You can hit 127.0.0.1 and link-local addresses, resolve internal hostnames like a redis or elasticsearch service, and port-scan the internal network by watching how responses differ. Reaching internal services walks the network view and how to enumerate it.

Cloud metadata abuse

The single highest-impact SSRF outcome is reaching the cloud instance metadata service and stealing the credentials it hands out. AWS, GCP, and Azure each expose an internal endpoint that returns the instance identity and temporary role credentials. Cloud metadata abuse covers the exact endpoints, the AWS IMDSv2 token handshake, and why some setups are harder to reach than others.

Defeating URL filters

Once developers know about SSRF they add a check: block 127.0.0.1, block the metadata IP, only allow certain hosts. Those checks are notoriously leaky, because an address can be written many equivalent ways and a hostname can change what it resolves to between the check and the fetch. Allow-list and filter bypass covers alternate IP encodings, the userinfo @ trick, open-redirect chaining, and DNS rebinding.

From SSRF to compromise

SSRF is a launchpad, not usually the endgame. With protocols beyond HTTP you can send arbitrary bytes to an internal service, and with stolen metadata credentials you can move into the cloud control plane. SSRF to RCE and compromise covers gopher:// byte-smuggling into services like Redis, dict:// and file://, and chaining credentials into full takeover.

Pivoting through a network

A single SSRF is a periscope into a whole subnet. Internal network pivoting is about using that one foothold to map live hosts, chain from one internal service to the next, and reach the thing that was never meant to face the internet. This is where multi-host practice matters, because a single-page lab cannot model a network you move through.

A worked example

Say an app has a "import avatar from URL" field. You set it to http://your-listener.example/ and a request lands in your logs, so the server fetches whatever you give it. You switch to http://127.0.0.1/ and the response is a default internal page, confirming you can reach loopback.

Now you aim higher: http://169.254.169.254/latest/meta-data/iam/security-credentials/. The response lists a role name. You request that role, http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>, and the server returns a set of temporary cloud credentials. Those keys, issued to the instance, now let you talk to the cloud account's APIs as that role. One avatar field became credential theft. That is the loop on every target: confirm the fetch, reach something internal, then escalate to what the server's identity unlocks.

Prevention

• Validate the resolved IP, not the string. Resolve the hostname, check the address against a deny-list of loopback (127.0.0.0/8, ::1), link-local (169.254.0.0/16), and all RFC1918 private ranges, and pin that address for the actual connection so it cannot change under you.
• Re-validate on redirects. Follow no redirect to a disallowed host, and check every hop, not just the first URL.
• Disable unused schemes. Allow only http and https. Kill file, dict, gopher, ftp.
• Harden the metadata path. Enforce AWS IMDSv2 with a hop limit, and prefer workload identity over long-lived keys so a leaked credential is short and scoped.
• Isolate the fetcher. Put the service that makes outbound requests on its own segment with egress firewalling, so even a successful SSRF reaches nothing valuable.

A WAF or a string blocklist is a speed bump. Validate the destination you will actually connect to, and assume the attacker can spell any address five different ways.

Where to go next

Work through the cluster in order, or jump to what you need. Start with basic SSRF, then blind SSRF and reaching internal services. When you want every target and bypass in one place, the SSRF cheat sheet has them. And when you are ready to break something real, sign up free and start hacking.