Preventing SSRF in file uploads

SSRF — Server-Side Request Forgery — is the class of bug where your server makes an HTTP request on behalf of a user to a URL the user controls. The classic case: a profile-picture import feature that takes a URL and fetches the image. The attacker gives you http://169.254.169.254/ and suddenly your server is handing the cloud metadata endpoint to the internet.

Block the private IP space#

At the simplest level, resolve the hostname and reject the request if the IP falls in any reserved range: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, and the IPv6 equivalents. Don't forget ::1 and fd00::/8.

Validate after redirects#

Your HTTP library follows redirects by default. An attacker-controlled URL can redirect to a metadata endpoint. Re-check the destination IP on every hop, not just the first request.

Prefer signed URLs and direct upload#

Better than proxying user-supplied URLs: let the browser upload directly to S3 with a presigned URL. The server never makes the request; there's no SSRF surface. Works for 95% of "let users upload a file" product requirements.

Rebind attacks#

DNS rebinding: the hostname resolves to a public IP at validation time, then rebinds to a private IP by the time you actually fetch. Mitigations include pinning the resolved IP for the request and using a dedicated fetcher that does both DNS resolution and request from the same socket.

A dedicated egress proxy#

For enterprises, the most bulletproof answer is an outbound proxy that only routes to an allowlist. Your application can't talk to internal infrastructure even if the code is compromised.