HTTP 3xx Redirects

How 3xx Redirects Work

HTTP 3xx responses tell the client that the resource is available at a different location, so the next request should go to a new URL instead of the one originally requested. The redirect target is usually conveyed in the Location header, and the client may keep the same method or change it depending on the status code.

That distinction matters because a redirect is not just a navigation hint, it is part of the request flow. Some 3xx codes preserve the original semantics more closely, while others intentionally change how the follow-up request is made. In practice, redirects are used by browsers, APIs and identity flows wherever a client must be guided to a canonical or temporary destination.

Common Uses and Behaviour

Redirects are most visible in content moves, canonical URL selection and temporary rerouting during maintenance, migration or load balancing. A permanent redirect tells clients and search engines that the old URL should no longer be treated as the primary one, while a temporary redirect preserves the expectation that the original URL may return later.

Because the client follows the redirect automatically, the server that issues the 3xx response is effectively shaping where the user or application goes next. That makes redirect choice important for web architecture, caching behaviour and user experience. It also means the destination must be carefully controlled, especially when the target is derived from user input or application state.

Security and Trust Implications

Redirects are usually harmless when the destination is fixed and well understood, but they become risky when the target can be influenced by an attacker or an untrusted parameter. Open redirect conditions can be used to send users to a malicious site that appears to come from a trusted domain, and redirect chains can obscure the final destination or create weak points in login and link-handling flows.

Redirects also interact with authentication and session flows. If a redirect URI or post-login destination is not tightly validated, the redirect mechanism can be abused to leak tokens, misroute users or weaken trust in the original site. That is why redirect handling must be treated as part of the application trust boundary, not just as presentation logic.

Implementation Details That Matter

Implementation details determine whether a redirect is safe and predictable. The status code chosen affects method preservation, caching and client behaviour, so the redirect type should match the intended outcome rather than being selected arbitrarily. For example, a long-lived canonical move needs different handling from a temporary failover path.

Validation of redirect destinations is the most important control point. Applications should prefer allowlisted destinations, strict path matching or fixed internal routes over free-form return URLs. Where redirects are part of OAuth, SSO or deep-linking flows, the redirect target should be registered and checked exactly, not loosely matched by substring or pattern.

Risk and Threat Considerations

Redirects create security risk when the destination is attacker-controlled, weakly validated or chained through multiple hops. In those cases, a benign-looking URL can become a delivery path for phishing, token leakage, login abuse or destination spoofing, especially when users trust the original domain.

Failure mechanism: An application accepts or constructs an unsafe redirect target, then automatically forwards the client to a location the defender did not intend.

Impact: Users can be sent to malicious sites, authentication flows can be weakened, and sensitive parameters or trust signals can be exposed to an attacker-controlled endpoint.

Practitioner Guidance

What to watch for: Review any redirect that accepts a return URL, next URL or destination parameter, and treat it as a security-sensitive input. The safer pattern is to keep destinations constrained, explicit and easy to audit, rather than allowing arbitrary external URLs.

Practitioner takeaway: A redirect is only safe when the final destination is as trustworthy as the original request path.

Related resources from NHI Mgmt Group

• Why does HSTS matter even when an application already redirects HTTP traffic to HTTPS?
• What breaks when kube-apiserver forwards HTTP 3xx responses from an aggregated API server without sanitising them?
• How should security teams decide between WinRM over HTTP and HTTPS?
• What do teams get wrong about WinRM over HTTP security?