Skip to content
hashkey.bond

Archivesecurity

SSRF: When Your Server Fetches the Wrong URL

Any feature that fetches a user-supplied URL can be turned into a proxy into your private network.

Published
Reading time
1 min read

Server-side request forgery happens when an application fetches a URL controlled by an attacker. The request originates from your infrastructure, so it can reach metadata services, internal admin panels, and local ports.

Classic targets

  • Cloud metadata endpoints (the 169.254.169.254 class of address) that hand out credentials.
  • localhost services with no auth.
  • Internal DNS names that resolve to private ranges.

Defenses, layered

  1. Allowlist destinations when the feature permits it.
  2. Resolve, then validate: check every resolved IP against private/link-local/loopback ranges, and pin the connection to that IP to prevent DNS rebinding.
  3. Egress firewall: deny private ranges at the network layer.
  4. Disable redirects or re-validate every hop.
  5. Metadata hardening: require a token header (IMDSv2-style) so plain GETs fail.

The hard part

Validating the hostname string is not enough: DNS can resolve differently on the second lookup, and redirects can change the target. Validate the actual socket destination.

Takeaway: treat outbound fetches as untrusted input. Validate resolved IPs, block private ranges at egress, and never let redirects bypass the check.