Skip to content

CONCEPT Cited by 1 source

Server-side request forgery (SSRF)

What it is

Server-side request forgery (SSRF) is the attack class where an attacker coerces a server to make an unintended internal HTTP request on the attacker's behalf. The server is the confused deputy — it holds network reachability (inside a VPC, behind a firewall, next to a cloud-metadata service) that the attacker does not, and the attacker convinces the server to exercise that reachability.

Canonical verbatim framing from sources/2026-04-21-planetscale-webhook-security-a-hands-on-guide: "An SSRF is when an attacker causes your service to make an internal, unintended request within your own network."

Why webhook-sender services are a canonical target

The defining property of a webhook sender is that the user provides a URL and the service dispatches a request to it. This is SSRF by construction unless defended explicitly. Two attack shapes:

  • Information exfiltration. Attacker targets an internal metrics/admin endpoint; if the sender surfaces the response body in its UI/logs, the attacker reads what they could not reach directly. PlanetScale's example verbatim: "if a web server is running an internal metrics endpoint that responds to HTTP POST requests, an attacker could direct the webhook service to send a request to the service. If the webhook service displays the response in the UI, the attacker has now gained access to your internal metrics data."
  • Side-effect triggering. Internal POST-accepting endpoints (admin APIs, queue-enqueue endpoints, internal state- mutation services) are triggered by the webhook send as if by a legitimate internal caller.

Other canonical SSRF-target surfaces beyond webhooks: URL preview / metadata fetchers, image proxies, URL shorteners, server-side PDF renderers, XML external entity processors, any feature that accepts a user-supplied URL and fetches it server-side.

Primary attack targets

The internal addresses SSRF specifically aims at:

  • Cloud-metadata services. AWS IMDS at 169.254.169.254, GCP / Azure equivalents. Returns IAM credentials / instance metadata over HTTP without auth. Mitigation: private-IP-range blocking must include the link-local 169.254.0.0/16 range.
  • Private IPv4 ranges. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — RFC 1918 internal-use ranges.
  • Loopback. 127.0.0.0/8 and ::1 — reaches services on the same host (co-located admin consoles, local caches, etc.).
  • IPv6 link-local + unique-local. fe80::/10, fc00::/7.
  • Own-service public domains. An attacker pointing the webhook sender at the operator's own public services reachable by IP/DNS but still inside a trust boundary.

Defense composition

SSRF is hard to fully defend because attackers control the URL AND its DNS resolution AND can change DNS between check-time and send-time (see DNS rebinding). The canonical shape is defense in depth — no single layer is sufficient:

  1. URL validation at submission time (concepts/webhook-url-validation) — HTTPS only + private-IP blocklist + own-domain blocklist + post-DNS- resolution re-check.
  2. Isolated egress-proxy tier (patterns/isolated-egress-proxy-for-user-urls) — all outbound requests go through a proxy ( Envoy) that re-enforces rules after DNS has been re-resolved for the actual send. Closes the DNS-rebinding check-to-send gap.
  3. Network-level egress rules — firewall / VPC egress rules that structurally block the sender host from reaching internal IPs regardless of what the application or proxy does.
  4. Output sanitisation — if the sender surfaces response content in UI, sanitise it so even a successful SSRF returns nothing useful to the attacker.

Seen in

Last updated · 470 distilled / 1,213 read