SSRF Lab: Beat the URL Allowlist With a Redirect

This article explains a Server-Side Request Forgery (SSRF) vulnerability in which an allowlist-protected URL fetcher can be bypassed using HTTP redirects. The attacker submits an allowed URL that redirects to an internal system, and because the fetcher validates only the initial URL before following redirects, the internal request succeeds. This matters because SSRF attacks can expose sensitive cloud metadata and internal systems, as demonstrated by the 2019 Capital One breach affecting 100 million people.

• Allowlist validation checks only entry pointPreviewBot accepts URLs on an allowlist (example.com, wikipedia.org) and checks that the submitted URL matches the allowlist before fetching. However, it does not re-validate the destination after following HTTP redirects. This means an allowed URL becomes an entry point to request any internal address, provided that allowed URL responds with a redirect to the target.
• Redirect-following bypasses security perimeterWhen a URL on the allowlist returns an HTTP redirect response pointing to an internal address, the fetcher automatically follows that redirect without re-checking the new destination against the allowlist. The internal metadata endpoint, normally unreachable and protected by the allowlist, becomes accessible through this redirect chain.
• Attack requires attacker control or knowledgeThe attacker must either control a URL that passes the allowlist check (or know of one that does) and can respond with a redirect, or find an existing allowed URL that naturally redirects to internal systems. The attacker then submits this allowed URL to PreviewBot, which fetches it, follows the redirect, and returns the internal content.
• Cloud metadata endpoints are high-value targetsThe article references the 2019 Capital One breach, in which attackers used SSRF against a cloud metadata endpoint to expose data on approximately 100 million people. This demonstrates that internal metadata endpoints accessible via SSRF can lead to large-scale data compromise, making them a standard attack target.
• Validation must apply to every request hopThe core principle is that the allowlist check cannot run only once against the user-submitted URL; it must re-validate the destination address after each redirect or disable automatic redirect-following entirely. Without per-hop validation, the allowlist guards only the front door while the redirect carries the request past the security perimeter.
• Defense requires multiple complementary controlsThe article recommends re-validating each redirect destination, blocking private and loopback IP ranges after hostname resolution (not by string matching), requiring IMDSv2 and hardened metadata settings, and egress-filtering the fetcher to only reach necessary external hosts. No single control is sufficient; defense relies on layered validation and network restrictions.
• SSRF reached mainstream security classificationServer-Side Request Forgery and redirect-based allowlist bypass are described as standard SSRF escalation techniques. SSRF itself was added to the OWASP Top 10 as a standalone category (A10) in 2021, reflecting its prevalence and impact in real-world applications.

Bottom line: An allowlist that validates only the initial URL is insufficient protection against SSRF; if the fetcher automatically follows redirects, every destination must be re-validated, or redirect-following must be disabled entirely. Testing for this vulnerability requires pointing an allowed URL at a redirect under the attacker's control and observing whether the server follows it to an internal address.