← Learn

Definition

What is SSRF (Server-Side Request Forgery)?

We scanned nearly 2,000 AI-built apps and 1 in 8 shipped a high-severity flaw. Want to check yours?Scan free →

Server-Side Request Forgery (SSRF) is when an attacker gets your server to make an HTTP request to a destination they control, often an internal address it would not normally reach. Because the request comes from inside your network, it can reach private services, admin panels, or cloud metadata endpoints that hold credentials.

How it happens

Any feature that fetches a user-supplied URL is a candidate: a link preview, a webhook, an image importer. If the code fetches whatever URL it is given, an attacker supplies an internal address such as the cloud metadata IP, and the server dutifully retrieves it and may return the contents.

How to prevent it

Resolve the target's DNS and reject anything that points to a private, loopback, or link-local address, and re-check on every redirect so a public host cannot rebind to an internal one. Allow only http and https on expected ports, and where possible use an allowlist of destinations.

What this means for AI-generated code

When an AI tool builds a fetch-this-URL feature, it writes the direct version that just requests the input, because that is all the feature needs to work. The address filtering that makes it safe is extra code with no visible payoff, so it is left out.

Common questions

What is the cloud metadata endpoint that SSRF targets?

On AWS EC2, the instance metadata service is at 169.254.169.254. A request to that IP from inside the instance returns credentials for the instance's IAM role — temporary AWS access keys that can be used to access S3 buckets, call AWS APIs, and more. Google Cloud and Azure have similar metadata endpoints. An SSRF that reaches this IP can compromise the entire cloud account.

How do I prevent SSRF in a Next.js app?

Resolve the URL's hostname to an IP before fetching, then block RFC 1918 private ranges (10.x, 172.16-31.x, 192.168.x), loopback (127.x), and link-local (169.254.x). Re-check after every redirect in case a public host resolves to a private address. If the destination set is known in advance, an allowlist of domains is the strongest defense.

Is SSRF only a risk in backend code?

Yes, SSRF requires your server to make an outbound HTTP request based on user input. Client-side code fetches URLs from the user's own browser, not your server, so it is not vulnerable to the same attack. The risk is specifically in server-side code that fetches a URL supplied by an external caller.

Want to know if your app has this issue? Scan your live app or a public repo free, no account needed.

Scan my app →

Related: fix an SSRF-prone URL fetch

What Is SSRF (Server-Side Request Forgery)? Explained | Prbl