What is SSRF? Server Side Request Forgery Explained

Server side request forgery, or SSRF, is a flaw where an attacker supplies a URL and makes your server send the request on their behalf, reaching systems the attacker could never open directly. The user controls an address, the server fetches it, and the server’s trusted position on the network becomes the attacker’s. Any feature that takes a URL or a host name from a user and fetches it is a place SSRF can hide. This post explains how it works, why the cloud makes it worse, how to spot it, and how to shut it down.

The examples use a made up app so nothing here points at a real target.

What is server side request forgery?

It is a server fetching whatever address a user hands it, a weakness catalogued by MITRE as CWE-918. Picture an app called Acme Notes. It has a friendly feature: paste a link and it pulls a preview image for you. Behind the scenes the server does something like this.

POST /preview
{ "url": "https://example.com/photo.png" }

The server reads that URL, makes the request itself, and sends the result back. That is the whole feature, and on a good day it is harmless. The problem is the server will fetch whatever you put there, including addresses that belong to the inside of the network, not the public internet.

So an attacker stops sending a normal photo link and starts sending internal ones.

POST /preview
{ "url": "http://localhost:8080/admin" }

POST /preview
{ "url": "http://192.168.0.10/" }

Your server happily reaches those, because to the network the request is coming from a trusted machine, not from a stranger. The user could never open http://localhost:8080/admin in their own browser. The server can, and you just lent it to them.

Why is SSRF so dangerous in the cloud?

It is dangerous in the cloud because the server’s own credentials sit one internal request away. On a normal server SSRF lets an attacker map and poke at internal services: admin panels, databases, message queues, and other apps that were never meant to face the public. In a cloud setup it gets worse, because most cloud providers expose a metadata service at a fixed internal address that hands out configuration and, in some setups, temporary credentials.

If an app is vulnerable and the environment is not locked down, a request aimed at that internal metadata address can return secrets the attacker should never see. From there a small preview feature turns into a path toward the cloud account itself. That is the jump that makes SSRF a headline bug rather than a minor one, and the reason OWASP gives SSRF a category of its own in the Top 10 instead of filing it under general access control.

SSRF is rarely about breaking the server. It is about borrowing its position on the network, which is far more useful than anything the attacker has from outside.

Where does SSRF show up?

It shows up in any feature that accepts an address and fetches it for you, which is a longer list than most teams expect.

• Link previews and unfurlers. Anything that fetches a page to show a title or image.
• Webhooks. You let users register a URL to receive events. The server calls it. That is SSRF by design unless you constrain it.
• Document and image processors. Features that import a file from a URL, convert a page to a PDF, or load a remote image.
• Imports by URL. “Import your data from this address” style features.
• Hidden parameters. Fields like image_url, callback, dest, or feed buried in a request body.

Some of these are blind, meaning you never see the response. The server still made the request, so an attacker can use timing or out of band tricks to confirm it. Blind does not mean safe.

How do you find SSRF in an app?

You find it by reading the app for the assumption it is making. The app assumes the URL you hand it points somewhere public and harmless. So you test that assumption directly.

• List every feature that accepts a URL, host name, or address, including the ones hidden in JSON bodies and headers.
• Point one at an address you control and watch whether the server actually calls it. If it does, the server is fetching user input.
• Then ask the real question: can I aim it at something internal? Try a loopback address, a private range, and the cloud metadata address for your platform.
• For blind cases, use a request listener you own so you can see the server reach out even when the app shows you nothing.

This is the same habit behind most serious findings. You do not throw random payloads. You understand what the feature is for, notice the trust it is built on, and test whether that trust holds. For more on that mindset see how hackers find vulnerabilities.

How do you prevent it?

You prevent it by deciding, on the server, exactly where a request is allowed to go. You cannot fix the bug by blocking a list of bad strings, because there are too many ways to write the same address.

• Use an allow list of destinations. If the feature only ever needs to reach three known providers, allow those and refuse everything else. An allow list beats a block list every time.
• Resolve the host first, then check it. Turn the host name into an IP address and reject anything that lands on a private, loopback, or link local range. Do the check after resolving, so a name that quietly points inside cannot slip through. Our free SSRF IP and URL normalizer expands the encodings and shorthand that hide an internal address so you can see where a value really resolves.
• Block the metadata address explicitly and require credentials on that service where your cloud supports it.
• Do not follow redirects blindly. A public URL can redirect to an internal one. Re check the destination on every hop.
• Isolate the fetcher. Run the part that makes outbound requests with no access to internal systems, so even a successful SSRF reaches nothing useful.

The theme is the same as most access control work: the server has to own the decision about what is allowed, not trust the input. If that idea is useful, the web and API security glossary defines SSRF and the terms around it in one place.

What should you take away?

Take away that SSRF is a quiet bug. The request looks ordinary, the feature works as designed, and the only thing wrong is where the server is willing to go. That is exactly the kind of assumption an autonomous researcher that studies how an app is meant to work is built to test, by understanding the feature, forming an idea about where the trust breaks, and proving it before calling it a finding. You can read more about UnboundCompute if that approach is interesting.

Frequently asked questions

What is server side request forgery in simple terms?

Server side request forgery, or SSRF, is a bug where an attacker supplies a URL and the server fetches it on their behalf, which lets the attacker reach addresses they could never open directly. Because the request comes from a trusted machine, the server can reach internal services like admin panels and databases. See the PortSwigger Web Security Academy SSRF topic for worked examples.

Why is SSRF so dangerous in cloud environments?

Most cloud providers expose a metadata service at a fixed internal address that can hand out configuration and, in some setups, temporary credentials. If an app is vulnerable and the environment is not locked down, a request aimed at that address can return secrets, which turns a small preview feature into a path toward the whole cloud account.

How do you prevent SSRF?

Decide on the server exactly where a request is allowed to go, using an allow list of known destinations rather than a block list of bad strings. Resolve the host name to an IP first and reject private, loopback, or link local ranges, block the metadata address, and do not follow redirects blindly.

What is blind SSRF?

Blind SSRF is when the server makes the request but never shows you the response. The attack still works, because an attacker can confirm the server reached out using timing or a request listener they own. Blind does not mean safe.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.