What is SSRF and why is the cloud metadata service a target?

Server-side request forgery (SSRF) is when an application takes a URL or address from user input and makes a request to it from the server. Think of a feature that fetches a remote image, validates a webhook, or imports a document from a link. The attacker supplies a URL the developer never intended, and the server — sitting inside the trust boundary — makes the request on the attacker's behalf.

Why the server's position is the prize

The server can reach things the attacker cannot: internal admin panels, databases, other microservices, and link-local addresses, all behind the firewall. SSRF effectively turns the vulnerable server into a proxy into the internal network, enabling internal port scanning and reaching unauthenticated internal APIs. The shapes these requests take — link-local addresses, scheme tricks, encoding bypasses — are catalogued in collections of SSRF payloads.

The cloud metadata twist

Cloud instances expose an instance metadata service at a link-local address (AWS/GCP/Azure use 169.254.169.254). It returns instance configuration — and critically, temporary IAM credentials for the role attached to the instance. An SSRF that reaches that endpoint can read those credentials and use them against the cloud account, escalating a single web bug into broad cloud compromise. This is the path behind several large breaches.

Mitigations

• IMDSv2 (AWS) requires a session token obtained via a PUT request with a hop limit, which a simple SSRF GET cannot perform — blocking the credential theft path.
• Allowlist outbound destinations rather than blocklisting; blocklists miss DNS rebinding, redirects, IPv6, decimal/octal IP encodings, and 0.0.0.0.
• Resolve and validate the target IP after DNS resolution, disable unneeded URL schemes, and isolate the fetcher in a restricted network segment.

Interviewers look for the "server makes attacker-chosen requests" definition, the metadata/IAM credential escalation, IMDSv2, and the insight that blocklisting is fragile so allowlisting is preferred.