An HTTP redirect is a server response that tells a client to request a different URL instead. It uses status codes such as 301, 302, 307 or 308, with the Location header naming the target, and can affect routing, canonical URLs and authentication flows.
How HTTP Redirects Work
An HTTP redirect is a control-flow response, not just a navigation convenience. The server tells the client to abandon the current URL and request a different one, usually by sending a 3xx status code with a Location header that identifies the next destination.
That handoff matters because the client, browser, crawler, or API consumer may preserve some request semantics while changing the destination. A redirect can be temporary or permanent, and the choice affects caching, indexing, and whether future requests should continue using the original URL.
Where Redirects Are Used
Redirects are common anywhere a resource needs to move without breaking existing links. They are used for canonical URL normalisation, site migrations, language or regional routing, trailing-slash cleanup, and entry-point consolidation from old URLs to new ones.
They also appear in authentication and authorization flows, especially when a browser must return to an application after sign-in. In those cases, redirect targets need careful validation because the destination can influence whether a user lands on the intended application path or is sent somewhere unintended.
For application and browser-based OAuth flows, redirect handling is part of the security design itself. The OAuth for Native and Mobile Apps Guide covers system-browser patterns, loopback redirect, and claimed HTTPS redirects that reduce the risk of interception or misuse.
Redirect Status Codes and Client Behaviour
Not all redirects behave the same way. Some codes suggest a method change after the redirect, while others preserve the original method and body. That distinction matters for form submissions, API calls, and login handshakes where repeating the wrong method can alter outcomes.
Redirects also interact with caching and search engines. A permanent redirect generally signals that the original URL has been replaced, while a temporary redirect says the original address remains valid. Misusing those signals can create stale caches, duplicate content, or inconsistent canonicalisation across clients.
Client behaviour is not perfectly uniform, either. Different browsers, libraries, and crawlers may treat redirects differently, especially when cross-origin navigation, cookies, or sensitive headers are involved. Security-sensitive applications should assume the redirect chain will be observed and sometimes replayed by intermediaries.
Security Implications of Redirects
Redirects can become a trust boundary when the destination is influenced by user input, query parameters, or application state. If the target is not tightly controlled, attackers can turn a legitimate redirect into an open redirect, use it for phishing, or abuse it to move users through trusted domains before sending them elsewhere.
Redirects can also leak authentication material if the destination is not handled carefully. A weakly validated return URL, a permissive mobile deep link, or an unsafe OAuth callback can expose users to token interception, session confusion, or app-link hijacking. The Mobile Deep Link and App Link Security Guide covers verified links, handler validation, and redirect uri protection in these flows.
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 OWASP ASVS sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Redirect handling is central to OAuth and OIDC callback security. |
| V7 — Session Management | Redirects can move authenticated users across trust boundaries and affect session handling. | |
| Recommendation — Validate redirect URIs and callback handling to prevent authorization code and session abuse. Preserve session integrity across redirects and reject destination changes that break expected session context. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe redirect configuration can expose clients to unintended destinations and trust-boundary failures. |
| Recommendation — Harden redirect configuration and block arbitrary destination selection in application and API flows. | ||
Practitioner Guidance
Why practitioners should care: Treat redirect targets as security-sensitive inputs, not cosmetic routing details. In authentication and app-link flows, the redirect destination often determines whether the user returns to a trusted context or is exposed to interception, phishing, or token leakage.
What to watch for: Validate that redirects are constrained to approved destinations, preserve the intended method only when required, and avoid allowing arbitrary URLs from request parameters. Review redirect chains during security testing, because the first hop may look harmless while the final hop creates the actual exposure.
Practitioner takeaway: A safe redirect is one whose target, purpose, and client behaviour are all explicitly designed, not assumed.