logo

Server-Side Request Forgery (SSRF)

Category:

Web Application

Summary:

How SSRF coerces a server into making attacker-controlled requests to reach internal services and cloud metadata, and how to detect and prevent it.

Server-side request forgery (SSRF) happens when an app fetches a URL supplied by the user, so the attacker gets the server — not the browser — to make the request. That reaches targets the attacker could never touch directly: cloud metadata endpoints (169.254.169.254), internal admin panels, and open proxies sitting behind the firewall. SSRF is a frequent path to credential theft, and chained calls can escalate it to command injection; it belongs to the same broad injection family as SQL injection.

Common Techniques

  • Cloud metadata theft — request the instance metadata service to pull temporary IAM credentials.
  • Internal port scanning — use response timing/errors from the fetch to map the internal network.
  • Protocol smuggling — abuse alternate schemes like gopher:// or file:// to reach non-HTTP services.
  • DNS-rebinding / allowlist bypass — a hostname resolves to an allowed IP at check-time, then to an internal one at request-time.
  • Blind SSRF via out-of-band callbacks — no response is returned, so confirm the request via a canary domain.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

logo-cta

Testing

Point every URL-accepting parameter at an out-of-band canary and at the cloud metadata address:

Terminal window
# out-of-band canary
curl "https://target/fetch?url=http://YOUR-OOB-DOMAIN/probe"
# cloud metadata
curl "https://target/fetch?url=http://169.254.169.254/latest/meta-data/"

A canary hit or a metadata response confirms SSRF. Note the parameter, the target reached, and any data returned in the pentest report so remediation can be scoped precisely.

Remediation

Enforce a strict allowlist of destination hosts and schemes rather than trying to blocklist bad ones. Block requests to link-local and private IP ranges at the network layer, disable unused URL schemes in the HTTP client, move to IMDSv2 or equivalent metadata guards, and isolate outbound egress so a compromised fetch can’t reach sensitive internal services.