SSRF Sentinel 2D: Server-Side Request Forgery Defense

Request Payload

Server-Side Defense

Server follows HTTP redirects

Auto-fire rate 1.0 req/s

Last Request

No requests fired yet.

Live Telemetry

Total requests

Blocked

Internal leaks

Leak rate

How it works

Server-Side Request Forgery (SSRF, OWASP A10) happens when a web app feature that fetches a URL on the user's behalf (image proxy, webhook, PDF renderer, "import from URL") can be pointed at destinations the attacker cannot reach directly — the internal network or, on cloud hosts, the instance metadata service (link-local 169.254.169.254, which serves IAM credentials with no auth).

classify(ip):
  169.254.169.254        → metadata   (critical: leaks cloud creds)
  10.0.0.0/8, 172.16/12,
  192.168.0.0/16         → private    (internal network)
  127.0.0.0/8, ::1       → loopback
  else                   → public

validate(url, mode):
  none       → always allow
  blocklist  → reject if the literal string matches known-bad
               patterns ("127.", "169.254", "192.168.", ...)
               ✗ bypassed by decimal/hex/octal IP encoding —
                 2130706433 == 127.0.0.1 but contains none of
                 those substrings
  allowlist  → reject unless hostname ∈ {approved domains}
               ✗ checked once, at parse time — a DNS record
                 that resolves to a *different* IP by connect
                 time (DNS rebinding), or a 302 redirect to an
                 internal target, both slip through unnoticed
  allowlist +
  re-resolve → same allowlist check, PLUS the IP is re-resolved
               and re-classified immediately before the socket
               opens, on every redirect hop — catches rebinding
               and redirect-based bypasses too

Payload — the URL the "fetch remote resource" feature is asked to retrieve, including two classic bypass techniques: numeric-IP obfuscation and DNS rebinding.
Server-side defense — which validation layer runs before the outbound socket opens; watch weaker modes leak requests that a stronger one blocks.
Follow redirects — real HTTP clients follow 3xx by default; an initial check that never re-runs on the final hop is a well-known SSRF bypass.

Real-world mitigation combines an explicit egress allowlist, re-resolving DNS immediately before connecting (not at parse time), disabling redirects on server-initiated fetches, and blocking the cloud metadata address at the network layer regardless of application logic.

Public internet (safe) Private / loopback network Cloud metadata (critical) Blocked at gateway

Drag to pan · Scroll to zoom