SSRF

Server-Side Request Forgery (SSRF) happens when an attacker can make a server send requests to destinations it wasn’t supposed to reach — often internal systems that aren’t exposed to the public internet at all. Instead of attacking a target directly, the attacker uses the vulnerable server itself as a proxy.

How It Works

Say an application has a feature to “fetch an image from a URL” for a user’s profile picture:

POST /fetch-image { "url": "https://example.com/photo.jpg" }

If the server blindly fetches whatever URL is provided, an attacker can instead submit an internal address:

POST /fetch-image { "url": "http://169.254.169.254/latest/meta-data/" }

That address is the cloud metadata service used by AWS, Azure, and GCP — often reachable only from inside the server itself. A vulnerable SSRF endpoint can be tricked into fetching sensitive metadata, including in some misconfigured environments, temporary cloud credentials.

Why SSRF Is Especially Dangerous in Cloud Environments

• Cloud metadata endpoints can leak IAM credentials, letting an attacker pivot into broader cloud infrastructure access
• Internal admin panels, databases, or microservices often trust requests coming from “inside” the network, with no additional authentication
• Firewalls that block external attackers do nothing to stop a request that originates from the trusted server itself

How Defenders Prevent It

• Allowlisting destinations — only permit the server to fetch from a known, explicit set of domains/IPs instead of anything the user supplies
• Blocking internal IP ranges (like 169.254.169.254, 127.0.0.1, and private RFC1918 ranges) at the network or application layer
• Disabling unnecessary URL redirects when fetching user-supplied URLs, since redirects can be used to bypass naive allowlists
• Using IMDSv2 or equivalent on cloud metadata services, which requires an extra token step that basic SSRF payloads can’t complete