SSRF Prevention for URL Fetchers: Validate Destinations and Redirects

A URL preview, image importer, or webhook tester can turn a server into a network client on behalf of a user. If the destination is unrestricted, the feature may reach services that the user cannot access directly. That is the basic danger behind server-side request forgery.

SSRF prevention needs more than rejecting a suspicious-looking string. A URL can parse correctly and still point to a private or unintended destination. The application must decide what it is allowed to fetch and enforce that decision at the network boundary.

Define the allowed purpose

Start with the feature's actual need. If it only imports from a small set of trusted services, a strict destination allowlist can be much simpler than allowing every public URL. If arbitrary public URLs are necessary, the defence needs more careful network and parsing controls.

The OWASP SSRF prevention guidance distinguishes these situations. Don't copy one validator across both without understanding the different requirements.

Record accepted schemes, ports, hostnames or address classes, redirect behaviour, response size, and time limits. This turns “fetch a link safely” into a contract reviewers can test. A denylist of a few known bad strings isn't a complete policy.

Parse once with a supported URL library

Use the platform's maintained URL parser rather than assembling host checks with ad hoc string splits. Reject unsupported schemes and unexpected user-information components according to your policy. Compare the actual parsed hostname, not a brand word elsewhere in the string.

Canonicalisation matters, but repeated decoding can also change meaning. Validate the representation your network client will use. Don't approve one interpretation and then send another after a later helper transforms the address.

For synthetic encoded components, URL Decoder can illustrate the text representation. It doesn't validate a complete URL, classify an IP address, or make a destination safe. Keep private addresses and credential-bearing URLs out of shared examples.

Check the resolved destination

For arbitrary public fetches, enforce the intended address policy after resolution and at connection time through an appropriate implementation. Private, loopback, link-local, and other disallowed destinations need more than a check for one dotted IPv4 form.

Consider IPv6 and DNS changes. A hostname passing one lookup can resolve differently later, and a client may choose an address you didn't inspect. Use a network design or supported fetch service that binds validation to the actual connection rather than relying on an unrelated preliminary query.

DNS Lookup can inspect public records for a benign hostname you own, but it is not an SSRF protection mechanism. The result of an external query doesn't constrain what your server's network client will connect to.

Handle redirects as new destination decisions

A permitted initial URL can redirect somewhere disallowed. Either disable automatic redirects when the feature doesn't need them or validate every hop using the same destination policy. Bound the number of hops and reject loops.

Don't forward sensitive request headers blindly to a redirected host. A fetcher shouldn't turn an authorised request to one service into credential disclosure to another. Decide which headers the feature needs and avoid sending user-supplied arbitrary headers by default.

The public Redirect Checker can show hops for benign URLs, but don't submit malicious, internal, or token-bearing addresses to it. It is not a sandbox for testing attacks or a replacement for your server's enforcement.

Bound the response and computation

Set connect and total deadlines, response-byte limits, and supported content types according to the feature. A public destination can still send an enormous response, an endless stream, or content that triggers expensive processing.

Read incrementally where the implementation supports it and stop once the allowed limit is exceeded. Don't check the advertised content length only after downloading everything. Treat absent or misleading length information as something the client must handle.

Avoid exposing raw upstream errors to users. They can reveal internal destinations or network details. Return a safe failure category and preserve restricted diagnostic evidence for the responsible team.

Use network restrictions as a second boundary

Restrict outbound connectivity where your hosting environment supports it. Keep the fetcher separate from sensitive internal services when practical. Application validation can fail, so a network boundary can reduce what a compromised or mistaken fetcher reaches.

Review platform-specific fetch behaviour and metadata-service protections in official documentation. Don't assume all clouds, runtimes, or containers have the same network model. A local test may not represent the deployed environment.

For hosted inference systems with tools that fetch URLs, see self-hosted AI data boundaries. An agent's inference location doesn't determine the reach of its network tools.

Test policy violations safely

Use a controlled test environment with endpoints you own to exercise disallowed address classes, redirect changes, oversized responses, and timeout paths. Don't probe third-party internal services or cloud metadata endpoints as casual tests.

Confirm that rejected requests don't initiate the prohibited connection. Testing only the returned error can miss a client that fetched first and rejected afterward. Preserve evidence of the network decision as well as the application response.

Conclusion

A parsed URL is still an untrusted destination request. Define the purpose, validate the actual connection and every redirect, bound responses, and restrict egress. Prove that prohibited destinations are never contacted rather than assuming an error message means the boundary held.