An SSRF attack — server-side request forgery — abuses functionality that makes a server fetch a URL, tricking that server into sending requests to a destination the attacker chooses. Because the request originates from inside your infrastructure, it can reach places an outside attacker never could: internal admin panels, databases on private networks, and cloud metadata services that hand out credentials. This post explains how an SSRF vulnerability arises, what attackers do with it, and the defenses that actually hold.
What Is an SSRF Vulnerability?
An SSRF vulnerability exists whenever an application takes a URL or address from user input and makes a server-side request to it without properly restricting where that request can go. The classic setup is innocent-looking: a feature that fetches a remote image, imports data from a URL, renders a webhook, generates a PDF from a link, or validates an avatar. The developer expects a public image URL. The attacker supplies something else.
The reason SSRF is dangerous is trust topology. Your server sits inside a network that trusts it. Firewalls that block the public internet let the server talk to internal services. Access controls that assume "if you can reach this endpoint, you belong here" apply to your own backend. When an attacker can steer your server's requests, they borrow all of that trust.
SSRF earned its own slot — A10 — in the OWASP Top 10 2021, added specifically because the community flagged how common and how impactful it had become in cloud-heavy architectures.
How Does an SSRF Attack Work?
The mechanics are straightforward. Consider an endpoint that fetches a user-supplied URL:
POST /api/fetch-image
Content-Type: application/json
{ "url": "https://example.com/logo.png" }
The server dutifully requests whatever is in url. An attacker replaces the value:
http://169.254.169.254/latest/meta-data/— the cloud metadata endpointhttp://localhost:8080/admin— an internal service bound to loopbackhttp://10.0.0.15:6379/— a Redis instance on the private networkfile:///etc/passwd— a local file, if the fetcher honors thefile://scheme
Each of these is a request the attacker could never make directly, now made on their behalf by a trusted server. From the target's perspective the request comes from a legitimate internal source.
What Can an Attacker Reach With SSRF?
The impact of an SSRF attack depends on what your server can reach, and in cloud environments that is often a lot:
- Cloud metadata and credentials. The link-local address
169.254.169.254serves instance metadata on AWS, GCP, and Azure. On instances using the older AWS IMDSv1, an SSRF could read temporary IAM credentials directly — the pattern behind the widely reported 2019 Capital One breach, where an SSRF against a misconfigured environment was used to reach metadata and pull credentials for large-scale data access. IMDSv2's session-token requirement was introduced specifically to blunt this. - Internal services. Admin dashboards, message queues, databases, and microservices that assume the network perimeter protects them.
- Port scanning and service discovery. Response timing and error differences let an attacker map internal hosts and open ports through your server.
- Blind SSRF. Even when the response is never returned to the attacker, out-of-band techniques (watching for DNS or HTTP callbacks to attacker-controlled infrastructure) confirm the request fired and can still trigger state-changing actions.
Why Do Blocklists Fail to Stop SSRF?
The instinctive fix — block localhost and 127.0.0.1 — fails because the address space attackers can express is enormous, and parsers disagree about what a URL means. Bypasses that routinely defeat naive blocklists include:
- Alternate loopback forms:
127.0.0.1,127.1,0.0.0.0,[::1], and decimal or octal encodings of the same address - DNS names that resolve to internal IPs, including attacker-controlled domains pointed at
169.254.169.254 - DNS rebinding, where a hostname passes validation as a public IP, then resolves to an internal IP on the actual fetch — a time-of-check/time-of-use gap
- Open redirects on an allowed host that bounce the server to an internal target
- Non-HTTP schemes like
gopher://,dict://, andfile://that reach services HTTP checks never considered
The lesson: string matching against a denylist is a losing game because you are trying to enumerate infinite bad inputs.
How Do You Prevent SSRF Attacks?
Effective SSRF prevention layers several controls; no single one is sufficient.
- Allowlist, do not blocklist. If the feature only ever needs a fixed set of domains or a specific API, permit exactly those and reject everything else. An allowlist of known-good destinations is the strongest single control.
- Validate after DNS resolution, and pin it. Resolve the hostname, confirm the resolved IP is not in a private, loopback, or link-local range, and then connect to that validated IP — closing the DNS rebinding window. Reject
169.254.169.254, RFC 1918 ranges, loopback, and IPv6 equivalents. - Restrict schemes and disable redirects. Allow only
http/https, blockfile,gopher,dict, and friends, and do not follow redirects automatically — a redirect is just another attacker-controlled URL. - Segment the network. The server making outbound fetches should live where it cannot reach internal admin services or metadata. Egress firewall rules that deny by default turn a successful SSRF into a dead end.
- Enforce IMDSv2 (or your cloud's hardened equivalent). Require session tokens for metadata access so a simple SSRF cannot read credentials.
- Give the fetcher least privilege. If it is compromised, its IAM role should grant almost nothing.
Static analysis helps you find the vulnerable pattern before it ships: taint-tracking SAST and DAST flags user-controlled input flowing into an outbound HTTP client, which is exactly the SSRF signature. Pair that with the SSRF prevention checklist above so the pattern is fixed rather than merely detected. More attack walkthroughs live in our academy.
FAQ
What does SSRF stand for?
SSRF stands for server-side request forgery. "Server-side" because your server makes the malicious request, and "request forgery" because the attacker forges the destination the server contacts. It is distinct from CSRF (cross-site request forgery), which abuses a user's browser rather than a server.
Is SSRF only a cloud problem?
No, but the cloud makes it worse. SSRF has always let attackers reach internal services on private networks. Cloud metadata endpoints raised the stakes by putting credential-issuing services at a predictable internal address that a single SSRF can hit — which is why SSRF prevention and metadata hardening now travel together.
What is blind SSRF?
Blind SSRF is an SSRF vulnerability where the server makes the attacker-controlled request but never returns the response to the attacker. It is still exploitable: attackers use out-of-band signals like DNS or HTTP callbacks to confirm the request fired, map internal infrastructure by timing, and trigger state-changing actions that need no response body.
How is SSRF different from an open redirect?
An open redirect makes a user's browser navigate to an attacker-chosen URL; an SSRF makes the server itself send the request. They often combine: an open redirect on an allowlisted domain is a common way to bypass SSRF destination checks, bouncing the trusted server to an internal target.