Key takeaway: Server-side request forgery was a moderate issue until every cloud instance began serving credentials at a fixed unauthenticated address reachable only from the instance itself.
What Changed the Severity
Server-side request forgery means an attacker controls where your server sends a request. Historically the impact was internal reconnaissance — reaching an admin page or a database console not exposed to the internet.
Cloud infrastructure changed the calculation. Instances expose an instance metadata service at a link-local address, 169.254.169.254, which returns instance configuration and, critically, temporary credentials for the attached role. That endpoint is unauthenticated by design, because reachability from the instance was treated as sufficient proof of identity.
An SSRF flaw makes your server issue requests on the attacker’s behalf, so the attacker inherits that reachability. One vulnerable image-fetching endpoint becomes a credential disclosure, and from there the attacker holds whatever permissions the instance role grants.
Why Blocklists Fail
The instinctive fix is rejecting requests to 169.254.169.254. That fails because the address has many equivalent representations.
| Bypass | Example |
|---|---|
| Decimal encoding | http://2852039166/ |
| Octal encoding | http://0251.0376.0251.0376/ |
| IPv6 mapped | http://[::ffff:169.254.169.254]/ |
| Attacker DNS record | A hostname resolving to the address |
| Redirect chain | An allowed host returning a 302 to it |
| DNS rebinding | Resolves safe on validation, target on fetch |
Redirect following defeats naive validation completely: the initial URL passes every check, and the server obediently follows the redirect to the metadata address. DNS rebinding defeats it even when the resolved address is checked, because the second lookup returns something different.
Controls That Actually Hold
The reliable defences do not attempt to enumerate bad destinations.
Enforce IMDSv2 and require it. The session-oriented metadata service demands a PUT request to obtain a token, then requires that token on subsequent calls. Simple SSRF cannot issue a PUT with custom headers, and the response hop limit prevents proxied access. Enabling it optionally accomplishes nothing — the older version must be disabled.
Allowlist destinations rather than blocking them. If the feature fetches images from three known providers, permit those hostnames and reject everything else. An allowlist cannot be bypassed by a novel encoding because the encoding still has to resolve to a permitted host.
Resolve, validate, then connect to the resolved address. Validating a hostname and separately connecting by hostname permits rebinding. Resolve once, confirm the address is not private or link-local, then connect to that specific address.
Disable redirect following, or re-validate every hop against the same rules.
Isolate at the network layer. An egress policy that permits only required destinations turns SSRF into a failed connection. This is the strongest control because it does not depend on application code being correct.
Testing For It
Look for any parameter naming a URL, hostname or file path that the server fetches: webhook registration, avatar import, document conversion, link preview generation, PDF rendering. Each is a candidate.
Confirm the metadata service requires a token, then verify that a redirect to a private address is refused rather than followed.
The Bottom Line
Require IMDSv2 and disable the earlier version, allowlist destinations instead of blocklisting addresses, resolve before connecting, and restrict egress at the network layer so that a code-level mistake cannot reach anything valuable.
