Server-Side Request Forgery (SSRF) Skill

SSRF happens when an application fetches a URL that the server controls but the user supplied. The server makes a request on the user's behalf, and if there is no restriction on where it can go, the user can point it at internal services, cloud metadata endpoints, or localhost.

The classic SSRF target is http://169.254.169.254/latest/meta-data/ — the AWS metadata endpoint. From a server inside a VPC, that URL returns IAM credentials. A user who can supply the URL gets the credentials.

What to Check Before Writing Outbound-Request Code

1. Is the URL user-supplied? Any code where the destination URL or hostname comes from user input, a webhook payload, a URL parameter, or a database record that a user could have written is SSRF-exposed.

2. Is there an allowlist? User-supplied URLs must be validated against an explicit allowlist of permitted hostnames or domains before the request is made. A blocklist (blocking 169.254.x.x, localhost, 127.0.0.1) is insufficient — IPv6 equivalents, DNS rebinding, and decimal/octal IP representations bypass blocklists.

3. Are internal network ranges blocked at the network layer? Application-level allowlists must be backed by network-level controls. If a server can reach internal services, an allowlist bypass can still reach them. Confirm whether outbound requests from the application are network-restricted.

4. Does the response get returned to the user? Blind SSRF (no response returned) is lower severity than reflected SSRF (response returned to user). Both require mitigation, but reflected SSRF is the higher priority.