Mitigating SSRF and DNS Rebinding Attacks in Modern Web Architectures

Any web feature that accepts a URL from a user — for link previews, content fetching, or address shortening — is always vulnerable to Server-Side Request Forgery. An attacker can make an internal server reach out to cloud metadata, management ports, or a local database that should never be reachable from outside.

Why SSRF is uniquely dangerous

SSRF's value to an attacker lies in the server's position. Requests that originate inside the network slip past the perimeter firewall, often carry implicit credentials, and reach services that were never designed to face untrusted traffic.

The classic target is the cloud provider's metadata endpoint at 169.254.169.254, which can return temporary credentials with full permissions. But the targets that get forgotten more often sit on the internal network itself: admin panels, database interfaces, and monitoring services left without authentication because they are "only reachable from the inside anyway".

DNS rebinding and the gap between two moments

Validation that checks an IP address and then sends the HTTP request as a separate step has a fundamental flaw. There is a gap between those two steps, and an attacker-controlled DNS server can change its answer in the middle of that gap.

The sequence is simple. The attacker's domain first answers with a public address that passes validation. Milliseconds later, when the real request goes out, a second resolution returns 127.0.0.1. The server checks one address and connects to another — an attack known as TOCTOU, time-of-check to time-of-use.

Defenses that actually close the gap

The key is to eliminate that gap. Resolve once, verify the result, and open the connection directly to that verified IP address with the Host header set accordingly. That way there is no second resolution for an attacker to slip into.

Verification must cover every RFC 1918 private range, loopback, link-local 169.254.0.0/16, and their IPv6 equivalents, including IPv4-mapped addresses such as ::ffff:127.0.0.1. HTTP redirects must be re-validated at every hop, not just at the initial URL, because redirects are the easiest way to slip past a check that runs only once.

The layer you cannot skip

Address blocklists always lose to attacker creativity — decimal, octal, hexadecimal, and the many ways of writing IPv6 offer too many variations. A protocol and port allowlist is far more robust: permit only http and https, only ports 80 and 443, and reject everything else without exception.

Code-level defenses still need network-level support. Running the content fetcher on an isolated network segment with no route to internal subnets turns a successful SSRF from a serious incident into nothing more than a failed request. It is the two layers together, not either one alone, that make infrastructure genuinely secure.