What Is SSRF? Server-Side Request Forgery Explained

Most vulnerabilities let an attacker do something to your server. SSRF lets them do something with it. The server becomes a proxy: it sits inside your network, it's trusted by internal services, and in the cloud it often has access to credentials. If an attacker can control where it sends requests, all of that trust is theirs.

How SSRF works

Any feature that makes the server fetch a URL supplied, even partly, by a user is a candidate:

Importing an image, file or feed from a URL
Link previews and unfurling
Outgoing webhooks to a user-configured address
PDF or screenshot generation from HTML that can reference external resources
Document parsers that follow external references (for example XML external entities)
Integrations where the user provides a server address

The attacker submits a URL pointing somewhere the server can reach but they can't:

http://169.254.169.254/..., the cloud instance metadata service
http://localhost:8080/admin, an admin interface bound to localhost
http://10.0.3.17:9200/, an internal search cluster with no authentication
http://internal-billing.svc.cluster.local/, a service inside Kubernetes

Why the cloud made SSRF critical

Cloud virtual machines can query a metadata service at a link-local address for configuration, and with the older AWS IMDSv1, for the temporary credentials of the instance's IAM role, with a plain GET request. An SSRF on a web server becomes a cloud credential theft, and from there, access to whatever the role can reach.

That chain was at the heart of the 2019 Capital One breach, in which an SSRF in a misconfigured web application firewall was used to obtain role credentials and read data on over 100 million people from S3. Cloud providers responded with hardened metadata services. AWS's IMDSv2 requires a session token obtained with a PUT request and a custom header, which most SSRF flaws can't send. Google Cloud and Azure require a special request header for the same reason.

Where SSRF sits in the standards

SSRF got its own category, A10, in the 2021 OWASP Top 10, based on community survey results. In the 2025 edition it was merged into A01 Broken Access Control, which reflects how it's best understood: the server is crossing a trust boundary on behalf of someone who shouldn't be able to cross it. The weakness is CWE-918.

Worked example: Invoicely

Suppose Invoicely adds a feature: customers can put their logo on invoices by pasting an image URL. The PDF worker fetches it while rendering. A new attack tree leaf appears under "steal cloud credentials":

Step 1 (OR): submit a logo URL pointing at the metadata service, or at an internal hostname.
Step 2 (AND): the worker runs on an instance that still allows IMDSv1, and its response is embedded in the PDF (or leaks through error messages).

Scored on the current design, likelihood 3 × impact 5 = 15, high. The cheapest fix breaks the AND gate: enforce IMDSv2 on every instance, which removes the credential path even before URL validation is perfect. Better still, apply avoidance: let customers upload the logo file instead of fetching a URL at all.

How to prevent SSRF

Avoid fetching user-supplied URLs where you can. Uploads beat URL imports.
Allowlist destinations when you must fetch: specific hosts or domains, HTTPS only, standard ports only.
Validate after DNS resolution. Resolve the hostname, reject private, loopback, link-local and internal ranges (IPv4 and IPv6), then connect to the resolved address, so DNS rebinding can't swap it afterwards.
Don't follow redirects, or re-validate every hop.
Harden metadata: require IMDSv2 on AWS, and give instances the narrowest possible role (least privilege).
Restrict egress at the network layer. Run URL-fetching code in an isolated service whose firewall rules only allow the internet, not internal ranges.
Authenticate internal services. In a zero trust design, reaching an internal endpoint isn't enough to use it.

Finding SSRF in a threat model

SSRF is easy to miss because DFDs usually show inbound flows (users calling your API) and forget outbound ones. Add every outbound request to the diagram, include the metadata service and internal admin endpoints as elements, and look for any process that both accepts user input and can reach an internal trust zone. That combination is the SSRF risk.

Common mistakes

Blocklisting strings. "localhost" and "169.254.169.254" have dozens of alternative encodings: decimal IPs, IPv6, DNS names that resolve to them.
Validating the URL, then fetching it again. Validate and connect to the same resolved address.
Forgetting non-HTTP schemes. file://, gopher:// and others may be supported by the HTTP client library.

Key takeaways

SSRF makes your server fetch a URL the attacker controls, turning it into a proxy into your internal network.
In the cloud, the classic target is the instance metadata service, which can hand out temporary credentials.
Any feature that fetches a URL is a candidate: webhooks, link previews, imports, PDF and image rendering.
Defend in layers: allowlist destinations, block internal ranges after DNS resolution, require IMDSv2, and restrict egress.

Frequently asked questions

What is an example of SSRF?

An app lets users import a profile picture from a URL. An attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the server, running on an AWS instance with the older metadata service, fetches and returns the instance's temporary cloud credentials.

Is SSRF in the OWASP Top 10?

SSRF was its own category, A10, in the 2021 OWASP Top 10. In the 2025 edition it was folded into A01 Broken Access Control. The matching weakness is CWE-918.

How does IMDSv2 help against SSRF?

AWS's Instance Metadata Service version 2 requires a session token obtained with a PUT request carrying a special header before metadata can be read. Most SSRF flaws only let an attacker send simple GET requests, so they cannot obtain the token.

What is blind SSRF?

SSRF where the attacker never sees the response. It can still be used to scan internal ports, trigger actions on internal services, or confirm hosts exist through timing differences or out-of-band callbacks.