Redirect following is the client behavior of automatically requesting the next URL returned in an HTTP redirect response. In security-sensitive server code, this can be dangerous because an apparently harmless fetch can be bounced to internal hosts, loopback services, or sensitive endpoints after the initial request leaves the application.
Expanded Definition
Redirect following is not the redirect response itself, but the client-side choice to automatically trust and request the location supplied by that response. In security reviews, this matters most when server-side code or backend automation performs HTTP requests on behalf of a user, service, or workflow. A seemingly ordinary fetch can be turned into a request path that reaches unexpected destinations after the first hop leaves the application boundary.
The distinction is important because the risk is not limited to public websites. It also appears in internal tools, API integrations, webhook consumers, and data import jobs where the caller assumes the destination is fixed. If the application follows redirects without validation, it may be steered toward loopback services, internal admin panels, metadata endpoints, or other resources that should never be reachable from that context. Guidance across vendors is consistent on the core issue, but implementation details vary depending on the language runtime and HTTP library. The NIST Cybersecurity Framework 2.0 is useful here because it frames this as a control and resilience problem, not just a coding mistake.
The most common misapplication is assuming that a safe initial URL also means a safe final destination, which occurs when redirect handling is enabled without checking where the client is actually sent.
Examples and Use Cases
Implementing redirect following rigorously often introduces extra validation and testing overhead, requiring organisations to weigh automation convenience against the risk of unintended outbound requests.
- A backend service fetches a user-supplied URL for link preview generation and follows a redirect to OWASP guidance on server-side request forgery relevant to redirect-based abuse.
- An internal import job retrieves a vendor file from a trusted domain, but the response redirects to a loopback address that exposes a local admin service.
- A payment integration calls a callback URL and follows a redirect into an internal hostname, creating an unintended path to sensitive APIs.
- A cloud function resolves short URLs from a campaign feed, then automatically follows chained redirects into a metadata endpoint or private subnet resource.
- A security proxy or HTTP client library is configured to follow redirects by default, so a benign allowlisted domain becomes a bridge to a disallowed destination.
Because redirect behavior is often hidden inside libraries, teams should test both single-hop and chained responses, confirm whether host, scheme, and port can change, and decide when redirects must be disabled entirely. The issue is especially important in services that process untrusted input or reach across trust boundaries, where the final request target is more important than the original URL.
Why It Matters for Security Teams
Security teams care about redirect following because it can defeat hostname allowlists, hide the true egress destination, and create server-side request forgery paths that bypass perimeter assumptions. In practice, the danger is not just data exposure. It can also become a pivot point into internal services, cloud instance metadata, and administrative interfaces that were never intended to be reachable from the originating process. That makes redirect handling relevant to application security, network segmentation, and cloud hardening at the same time.
For identity and access teams, the connection appears when an automated service uses secrets or tokens to retrieve content on behalf of another workflow. If the client follows redirects automatically, those credentials may be presented to a destination outside the intended trust relationship. Controls from NIST CSF 2.0 and OWASP Top 10 align with treating destination validation, egress control, and safe default library configuration as core defensive measures.
Organisations typically encounter the impact only after an outbound request reaches a sensitive internal service, at which point redirect following becomes operationally unavoidable to contain the exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access pathways should be limited to intended destinations, preventing redirected requests from crossing trust boundaries. |
| NIST AI RMF | AI systems that fetch external resources can inherit redirect risks in their tool-use and retrieval flows. | |
| OWASP Non-Human Identity Top 10 | Automated identities and service credentials can be exposed when redirect handling crosses trust boundaries. | |
| NIST SP 800-53 Rev 5 | SC-7 | Boundary protection controls are relevant when redirects enable unexpected outbound network paths. |
Apply egress filtering and destination validation to stop redirected traffic from reaching restricted systems.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
