Redirect-following behaviour is the HTTP client pattern of automatically continuing to a new location when a server responds with a redirect. For identity and secret scanners, that behaviour can turn a seemingly safe lookup into a request against an internal host if destination revalidation is missing.
How Redirect Following Works
Redirect-following behaviour is a normal HTTP client feature: when a server returns a redirect status code, the client automatically requests the new location. That convenience is useful for canonical URLs, login flows and moved content, but it also means the client, not the server, decides whether to trust the next hop.
The key detail is that redirect handling is usually stateful. A client may carry headers, cookies, authentication material, request methods or body content into the follow-up request depending on the status code and implementation. That makes redirect logic a security-relevant boundary, not just a transport convenience.
Why Redirect Following Matters for Security
For scanners, crawlers and automation that handle secrets or internal lookups, redirect following can turn a request against a public endpoint into a request against an unexpected internal destination. The risk is not the redirect itself, but the fact that the client may be induced to leave the original trust boundary before the destination is revalidated.
This behaviour is especially important when a system is using URLs as inputs to discovery, verification or enrichment workflows. If the follow-up destination is not checked against an allowlist, redirect logic can become a path to unintended network reachability, data exposure or policy bypass.
Redirects also interact with request semantics. A follow-up to a different host can preserve enough context to reveal metadata, trigger side effects, or validate that a protected service exists. In security tooling, that can blur the line between a harmless lookup and an outbound request with real reach.
Common Failure Conditions
The most common weakness is treating the initial URL as the only thing that needs validation. If the redirect target is accepted implicitly, the client may follow chains across schemes, hosts or ports that would never have been approved directly.
Another failure mode is overbroad trust in redirect responses from authenticated or privileged contexts. A client that follows redirects while sending credentials, tokens or cookies can accidentally disclose secrets to a different origin if origin boundaries are not enforced carefully.
Implementation details matter too. Some clients normalise or rewrite methods across redirects, while others preserve them. Those differences can change whether the redirected request is read-only, state-changing or capable of reaching internal services in ways the original caller did not intend.
Safe Handling Patterns
Redirect-following should be treated as part of the input validation problem, not as an invisible HTTP default. The client should revalidate the destination, constrain the allowed redirect chain, and separate safe navigation from privileged or secret-bearing requests.
For security-sensitive workflows, the safest pattern is to decide in advance which origins are acceptable, then verify every redirected hop against that policy. This is especially important for identity, secret and metadata lookups, where even a single unintended follow-up request can expose information or confirm internal reachability.
When redirect handling is necessary, it should be explicit, observable and limited. A well-designed client makes redirect decisions easy to audit and difficult to misuse, which reduces the chance that convenience becomes an internal request primitive.
Risk and Threat Considerations
Redirect following becomes risky when an attacker can influence the destination of a follow-up request. That can enable server-side request abuse, internal host probing, credential leakage or policy bypass if the client automatically trusts the new location.
Failure mechanism: The client accepts a redirect before revalidating the target, then issues a second request to an origin or network location that was never intended to be reachable from the original input.
Impact: Sensitive scanners, automation and application flows can disclose secrets, confirm internal services, or act as a bridge into otherwise protected network paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API7 — Server Side Request Forgery | Redirect following can steer a server-side request to an attacker-chosen target. |
| Recommendation — Constrain redirect destinations and block untrusted follow-ups that could enable SSRF. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Redirect handling can cross trust boundaries if follow-up destinations are not controlled. |
| Recommendation — Validate redirected destinations against boundary policy before allowing the next request. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Unexpected redirect chains can create observable outbound paths worth monitoring. |
| Recommendation — Alert on unusual redirect-driven outbound requests and constrain egress where feasible. | ||
Practitioner Guidance
What to watch for: Review any code path that automatically follows redirects in contexts that handle secrets, credentials or internal lookups. Redirects are usually safe only when the follow-up destination is non-sensitive, expected and explicitly constrained.
Governance implication: Teams should define whether redirect following is allowed by default, under what trust conditions it is acceptable, and which classes of requests must never inherit automatic follow behaviour.
Practitioner takeaway: If the redirected destination matters to your security decision, treat redirect following as an authorization boundary and not just an HTTP convenience.