Server-Side Request Forgery
also called SSRF
Inducing a server to make an HTTP request to an attacker-chosen destination, turning it into a proxy into networks and services the attacker cannot reach directly.
The application accepts a URL — for a webhook, an image fetch, a document import, a link preview, a PDF render — and requests it. If the destination is not constrained, the attacker points it at internal addresses.
What makes it severe in cloud specifically is the instance metadata service at 169.254.169.254,
which historically returned credentials to any process that asked. SSRF plus metadata plus an
over-permissive role is the chain behind the Capital One breach and several others.
The defences, in order of strength:
Do not fetch attacker-supplied URLs where the requirement can be met another way.
Allow-list destinations rather than block-listing, because block-lists are defeated by redirects,
DNS rebinding, IPv6 representations, decimal-encoded addresses and the many forms of 127.0.0.1.
Egress filtering at the network layer, so the application cannot reach internal ranges regardless of
application-level bugs. This is the control that works when the code is wrong.
IMDSv2 or its equivalents, which require a session token obtained by a PUT and default to a hop
limit that blocks proxied requests — breaking the credential-theft step structurally.
Resolve and validate the address after DNS resolution, and re-validate on every redirect.
And the assumption to hold: SSRF is a bug class that recurs, so the network and IAM controls matter more than the application fix.