Your backend service calls third-party URLs with an HTTP client that automatically follows redirects. What controls would you place on that redirect-following behaviour before shipping it?

## Why redirects deserve their own threat model When your service fetches a URL - a webhook target, an image the user linked, an OpenID discovery document - you typically validate that URL: right scheme, allowed host, not an internal address. Automatic redirect following silently discards that guarantee. The remote server, which may be attacker-controlled or merely compromised, now picks the next URL your service will request from inside your network perimeter. Validation performed once, on the first URL, protects nothing. ## Controls, in order of importance **Validate on every hop.** This is the whole game. The check that runs on the user-supplied URL must run again on each `Location`. A canonical attack: the user submits `https://harmless.example/x`; that host returns `302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/`; your service dutifully fetches cloud instance credentials and returns the body to the attacker. Blocking loopback, private (RFC 1918), link-local, carrier-grade NAT, and IPv6 equivalents including IPv4-mapped forms (`::ffff:169.254.169.254`) and unique-local addresses, on every hop, is the mitigation. **Resolve, validate, then connect to the resolved address.** Validating a hostname and then handing the hostname to the socket layer leaves a time-of-check/time-of-use window: DNS rebinding returns a public address to your validator and a private one to the connect. Resolve once, check the resulting IPs, connect to a checked IP with the original `Host` and SNI preserved. **Cap hops and set a chain-wide deadline.** Each hop is a fresh connection to a possibly slow host. A per-request timeout applied per hop multiplies by the hop count, so a 10-second read timeout with 20 hops is a 200-second hang holding a thread and a connection. Use one deadline for the whole operation, and a hop cap of a handful. **Cap response size, on every hop.** A redirect chain can end at a multi-gigabyte body or a decompression bomb; enforce a byte ceiling while streaming rather than after buffering. **Scheme discipline.** Follow only http and https, never a downgrade from https to http (which exposes the request to the network), and never non-HTTP schemes. Some clients historically followed `file:` URLs, turning a fetcher into an arbitrary file reader. **Credentials.** Confirm your library drops `Authorization`, cookies, and proxy credentials across origins - and never set curl's `--location-trusted` or a library's equivalent for third-party URLs. If you attach an internal service token to outbound calls, ensure it cannot ride a redirect to an external host. **Observability.** Log the requested URL, each hop, and the final effective URL, plus a metric for hop counts. Chains that suddenly get longer are a signal, and incident response needs to know what was actually fetched, not what was asked for. ## The stronger option: do not auto-follow For untrusted URLs, configure the client with redirect following **disabled** and handle 3xx responses yourself: read the `Location`, resolve it against the request URI, run the same validation pipeline used for the original input, decrement your own hop budget, and issue the next request explicitly. This costs a dozen lines and turns an invisible policy inside a library into code you can test - including negative tests asserting that a redirect to a private address is rejected. ## Related design considerations - **Egress isolation.** The strongest control is architectural: perform untrusted fetches from a network segment or proxy that has no route to internal services or metadata endpoints. Then a validation slip is not automatically an incident. - **Idempotency of the fetch.** Redirect-following re-sends non-idempotent requests when the method is preserved; for outbound webhooks, decide explicitly whether a redirected POST may be delivered twice. - **Library defaults drift.** Redirect limits, credential stripping and scheme rules differ across libraries and change across versions. Pin the behaviour with tests rather than trusting documentation.