Validating a hostname and then letting your HTTP client resolve it again leaves a gap. An attacker's DNS can answer differently the second time and point at an internal address. The fix is to resolve once, check every returned address, and connect only to an address you validated.
The gap
The usual flow looks safe. A user submits a URL. Your code looks up the domain, sees a public address and approves it. Then the HTTP library does its own lookup when it opens the connection.
That is two lookups. Between them, the answer can change. This is the idea behind DNS rebinding, and the OWASP SSRF cheat sheet states that allow-listing domain names alone does not stop it.
The pattern OWASP describes
According to the cheat sheet:
- Resolve the domain.
- Check every returned address against the networks you permit.
- Make the HTTP client connect only to a validated IP.
- Keep the original hostname for the Host header, SNI and certificate verification.
- Apply the same checks to retries and fallback connections.
Point 4 is easy to get wrong. If you connect by IP but forget to keep the hostname for TLS, certificate checks break or get switched off. Do not switch them off.
Point 5 matters because retry paths often take code that skips validation.
What does not replace it
The cheat sheet says DNS monitoring and internal resolvers help detect problems but do not replace connection-time enforcement. Logging is a good second layer. It is not the gate.
Related traps
- Redirects. A public URL can redirect to an internal one. Disable redirects, or validate each hop the same way.
- Parser differences. If two URL parsers read the same string differently, one may approve what another sends somewhere else. The cheat sheet says to treat any disagreement as a rejection.
- IPv6 and odd notations. Compare resolved addresses, not the string the user typed. Block IPv6 unique local and link-local ranges as well as the IPv4 private ranges.
- Returning the response. OWASP advises not to return raw remote responses to clients, which limits what an attacker learns even if a request slips through.
A test you can run
Stand up a test domain you control that alternates between a public and a loopback address. Submit it to your webhook or URL fetch feature. If the feature ever connects to the loopback address, your check and your connect are separate steps.
Do this only against your own systems.
Network layer backup
Application checks can have bugs. A firewall rule that stops the fetching component from reaching internal ranges and the metadata endpoint removes the payoff. See allow-list or deny-list for webhook URLs.
Quick check
Is resolving the name before connecting enough?
Only if the client then connects to that exact validated address. If it resolves again, rebinding is still possible.
Do I need this if I disable redirects?
Yes. Redirects and rebinding are separate routes to the same result.
Safeguard's dependency scanning can flag advisories in the HTTP clients you use, and the free scan at gold.safeguard.sh/scan gives a first look. Connection level validation is your code's job.
Sources
Last reviewed: 19 October 2026.
