Server-Side Request Forgery happens when an application fetches a URL supplied or influenced by a user, and an attacker can control where that fetch goes. Many features need this capability: a "fetch link preview" function, an avatar-by-URL importer, a webhook tester, a PDF generator that loads remote images, an integration that pulls data from a customer-supplied endpoint. Each of these takes a URL and asks the server to go get it. If the server doesn't carefully restrict the destination, the attacker chooses it.
The danger is that your server sits in a position of trust that an outside attacker does not. It can reach internal admin panels, databases, and cloud metadata services that are firewalled off from the public internet. SSRF turns the server into a confused deputy: a trusted party tricked into using its privileges for someone else.
The Cloud Metadata Jackpot
The most consequential SSRF target is the cloud instance metadata endpoint. On most cloud platforms, a special link-local address — historically 169.254.169.254 — serves configuration data to the running instance, including, in older setups, temporary credentials for the instance's IAM role. An attacker who can make the server request that address may read those credentials and then act with the server's cloud permissions.
This is not theoretical. The 2019 Capital One breach, which exposed personal data of roughly 100 million people, involved an SSRF vulnerability used to reach the metadata service and obtain credentials that could read storage buckets. SSRF moved from "interesting web bug" to "boardroom-level risk" largely because of that incident.
Cloud providers responded with hardened metadata services (such as AWS's IMDSv2) that require a session token obtained via a PUT request with a specific header — something a naive SSRF GET cannot perform. Enforcing the v2-only mode is one of the highest-leverage SSRF mitigations available, and it costs nothing.
Beyond Metadata: The Internal Network
Even without cloud credentials, SSRF lets an attacker explore your internal network from the inside:
- Port scanning — by requesting
http://10.0.0.5:8080and observing response times or errors, an attacker maps internal hosts and open ports. - Reaching unauthenticated internal services — admin dashboards, Redis, Elasticsearch, and message queues are frequently exposed without authentication on the assumption that "only internal traffic reaches them." SSRF makes the attacker internal.
- Protocol smuggling — depending on the HTTP client, schemes like
file://,gopher://, ordict://can read local files or craft raw TCP payloads to non-HTTP services.
Why Naive Defenses Fail
The obvious fix — "block requests to internal IPs" — is necessary but riddled with bypasses if implemented carelessly. Attackers have a deep toolkit:
| Bypass technique | How it evades a naive filter |
|---|---|
| DNS rebinding | A hostname resolves to a public IP when validated, then to an internal IP when fetched moments later |
| Redirects | A allowed public URL responds with a 302 to an internal address; the client follows it |
| Alternate IP encodings | Decimal, octal, hex, or IPv6-mapped forms of 127.0.0.1 slip past string checks |
| Wildcard DNS | Domains that resolve to 127.0.0.1 or link-local addresses by design |
The redirect and DNS rebinding tricks are particularly nasty because they defeat any check performed on the original URL string. The IP that gets validated is not the IP that gets connected to.
Defenses That Hold Up
SSRF is best defended in layers, with network-level controls doing the heaviest lifting because they don't depend on getting URL parsing perfect.
1. Allowlist destinations
If the feature only ever needs to reach a known set of domains, allowlist them. An allowlist of expected hosts is dramatically safer than a blocklist of forbidden ones, because the default is deny.
2. Validate at connection time, not parse time
Resolve the hostname, check the resulting IP against blocked ranges (loopback, link-local, RFC 1918 private ranges, your cloud metadata address), and then connect to that exact IP — pinning it so a rebind between check and use is impossible. Disable or strictly re-validate redirects.
3. Isolate the egress path
Route outbound fetches through a dedicated, locked-down egress proxy that cannot reach the internal network or metadata endpoint at all. This is defense in depth: even a perfect URL bypass lands in a network segment with nothing valuable to reach. It also embodies zero-trust thinking — the fetcher is treated as untrusted and given only the connectivity it strictly needs.
4. Enforce hardened metadata services
Require IMDSv2-style token-based metadata access, and scope instance IAM roles to the minimum. Assume SSRF will happen and ensure the credentials it could reach are nearly worthless.
The most robust SSRF posture treats every server-initiated outbound request as untrusted and confines it to a network segment where reaching anything sensitive is impossible by construction — not merely forbidden by a filter.
How This Shapes Haven's Architecture
SSRF is one reason Haven's backend on the Core server is forbidden from egressing directly to external hosts. Any outbound HTTPS the system needs — fetching a remote resource, talking to a third-party API — is funneled through a dedicated egress proxy on a separate machine, so the application server itself cannot be tricked into reaching internal services or a metadata endpoint. The same instinct drives the image proxy: remote email images are never fetched by the client or pulled into the trusted network directly; they pass through a controlled intermediary. SSRF defense, like data minimization, is ultimately about removing capability the system doesn't need, so that a single bug can't be parlayed into a breach.