Block SSRF Redirect Chains with a Four-Layer Policy

An SSRF vulnerability can emerge when a URL fetcher follows redirects to private networks. A multi-layered defensive pattern, including a trust boundary model and an address gate, can prevent this bypass.

A seemingly innocuous URL like https://example.invalid/report can mask a critical server-side request forgery (SSRF) vulnerability. The dev.to article by jaryn_123 demonstrates how an initial public DNS lookup can be bypassed by a subsequent redirect to a private network address, such as http://169.254.169.254/latest/meta-data/. This scenario highlights a core security blind spot: a URL is not a single, static network destination.

Initial validation of a URL's hostname or its first DNS resolution is insufficient. Malicious actors can exploit HTTP redirects and dynamic DNS changes to pivot from an allowed public destination to a restricted internal resource. The invariant for secure URL fetching, according to the article, is that "Every connection attempt must target an address allowed by policy, and every redirect must receive a new authorization decision."

The Trust Boundary

The article establishes a 'trust boundary' model, delineating a chain of values that must each be considered untrusted and distinct. This chain includes the user-submitted URL, the parsed URL, normalized hostname, DNS answer set, selected socket address, HTTP redirect target, and subsequent DNS answer sets. Failing to check each step—for instance, by only validating the initial hostname—creates gaps where malicious redirects or DNS changes can lead to private network access. The Host header alone is not enough; allowing the HTTP library to resolve independently introduces a time-of-check/time-of-use gap.

A Four-Layer Policy

To counter this, a four-layer policy is proposed, each with specific rejection criteria. The first layer, Scheme, rejects anything beyond explicitly supported https: or http:. URL syntax validation then filters credentials, malformed ports, and ambiguous hostnames. The Resolution layer blocks loopback, private, link-local, multicast, and unspecified addresses. Finally, Navigation ensures redirects adhere to a hop limit and re-evaluate the entire policy for each new target, preventing an allowed initial request from becoming an authority to contact a different, unauthorized host.

Minimal Address Gate Example

A Node.js code example, blockedIPv4, illustrates a minimal address gate. This function parses an IPv4 address into its octets and checks for high-risk ranges. The author notes that Node's net.isIP() identifies syntax but requires additional CIDR classification for comprehensive policy enforcement. The example explicitly covers common IPv4 private ranges, but the author states production code requires a maintained IP/CIDR library and a complete IPv6 policy. This snippet provides a functional starting point for blocking specific IPv4 ranges, but it is not a complete solution.

What We'd Change

The blockedIPv4 example, while illustrative, is explicitly noted as minimal. For production, relying solely on net.isIP() for syntax and a custom blockedIPv4 function is insufficient. A full implementation requires a robust, actively maintained IP/CIDR library to handle the complete spectrum of IPv4 and IPv6 private, loopback, and link-local ranges. This includes IPv6-mapped IPv4 addresses and the broader IPv6 policy, which the provided snippet omits. Manually maintaining a list of blocked CIDR ranges is prone to error and omission as network specifications evolve.

Furthermore, the complexity of implementing and continuously updating such a multi-layered policy can be substantial for indie founders. While essential for services handling arbitrary URLs, smaller applications with predictable external dependencies might consider stricter whitelist-only approaches for their URL fetchers. For broader use cases, integrating a dedicated, well-maintained security library or a cloud-based Web Application Firewall (WAF) with SSRF protection capabilities could offload significant engineering burden and reduce the risk of subtle bypasses.

Effective SSRF protection demands a continuous, multi-point validation strategy. Relying on initial URL parsing or a single DNS lookup leaves critical attack surfaces exposed. Founders building services that fetch external content must implement a dynamic, layered defense that re-evaluates trust at every stage of the connection and redirect chain, using robust, battle-tested libraries for IP classification and policy enforcement.

The investor read

The increasing sophistication of SSRF attacks, particularly those exploiting redirect chains, signals a growing need for robust, multi-layered security primitives in SaaS applications. Companies building URL preview, import, or webhook services face heightened liability. Investment opportunities may emerge in specialized security libraries or services that abstract away this complexity, offering validated, up-to-date IP classification and request gating. For bootstrapped founders, this pattern underscores the non-trivial engineering cost of secure URL fetching, pushing some towards managed services or stricter whitelist-only approaches to mitigate risk and development overhead.

Pull quote: “Every connection attempt must target an address allowed by policy, and every redirect must receive a new authorization decision.”