Open Redirect Guide: Safe Redirects and OAuth Redirect URI Validation

An open redirect is an endpoint on a trusted domain that sends the browser to any destination supplied in the request, letting attackers borrow your domain's reputation for phishing and, in OAuth flows, steal authorization codes and tokens. The flaw is often dismissed as low severity because it does not expose data by itself. That view misses how it is used: as the first hop of credential phishing campaigns that need a link to look legitimate, and as the missing piece that turns a loose redirect URI policy into account takeover. This guide covers how open redirects work, where they appear, how to find them and how to design redirect handling that is safe, including redirect URI validation for OAuth authorization servers and clients. It is written for developers, application security engineers and identity teams.

Key takeaways

• Do not redirect to user-supplied URLs. The OWASP cheat sheet's first advice is to avoid redirects driven by input; where a destination must vary, map an identifier to a server-side list.
• Validate parsed URLs, not strings. Use a maintained parser, then check scheme, host and port against an allowlist; prefix, suffix and substring checks are routinely bypassed.
• OAuth needs exact matching. RFC 9700 requires authorization servers to compare redirect URIs by exact string match against pre-registered values, with a single exception for localhost ports in native apps.
• An open redirect anywhere on a redirect URI host is an OAuth flaw. RFC 9700 says clients and authorization servers must not expose open redirectors, because they can carry codes and tokens to an attacker.
• Treat it as a phishing enabler. Mail and web filters see the trusted domain first, so open redirects on your domain are used against your customers and other organisations.

How the attack works

MITRE defines the weakness as CWE-601, URL Redirection to Untrusted Site ('Open Redirect'): an application accepts user-controlled input that specifies an external link and uses it in a redirect. The mechanics are simple. A parameter such as returnUrl, next, continue or target is copied into a Location header (HTTP 301, 302, 303, 307 or 308), a meta refresh, or a client-side assignment to window.location. Whoever controls the parameter controls where the browser lands.

Three ways it is abused

• Phishing link laundering: the attacker sends a link whose visible host is your domain. The recipient, a mail filter or a URL reputation service sees a trusted host; the browser then lands on a lookalike sign-in page. Microsoft Threat Intelligence described a campaign in August 2021 that embedded the final malicious URL as a parameter of open redirector links on trusted domains, added a CAPTCHA step that likely helped evade automated analysis, and ended on a fake Office 365 sign-in page; Microsoft observed at least 350 unique phishing domains in it. This maps to ATT&CK T1566.002 (Spearphishing Link) and T1204.001 (Malicious Link).
• OAuth code and token theft: if an authorization server accepts redirect URIs by pattern, or a client hosts an open redirector on a registered redirect URI host, the authorization response can be bounced to the attacker. RFC 9700 section 4.1.2 describes how a client's redirector can forward a token-bearing response and how browsers reattach the URL fragment on the onward redirect, so the attacker's page receives the token. This is a route to ATT&CK T1528 (Steal Application Access Token).
• Authorization server as redirector: RFC 9700 section 4.11.2 notes that even with valid registered URIs, an attacker who registers their own client can use the authorization server to send users to a phishing page, for example through an error response, a declined consent or a silent prompt=none request.

Two adjacent risks share the same root cause. Server-side forwards that take a destination from input can reach functions the user should not access, which the OWASP cheat sheet treats as an authorisation problem. Backend code that follows redirects when fetching URLs is a server-side request forgery concern; ASVS V15.3.2 asks that backends do not follow redirects unless intended. See the SSRF Prevention Guide.

Where it shows up

Impact

• Credential theft at scale: CWE-601 lists phishing as a primary consequence, because links appear to start with a trusted domain. Users and filters who check the domain are both misled.
• Account takeover through OAuth: a stolen authorization code or access token grants access without the password or MFA. Where the token belongs to an integration rather than a person, it is a non-human identity credential that can persist well beyond the original session. See the OAuth Token Theft Incident Playbook.
• Malware delivery: CWE-601 also lists redirects to malicious downloads and drive-by pages.
• Script execution: client-side redirects that accept non-HTTP schemes can become cross-site scripting. See the Cross-Site Scripting (XSS) Prevention Guide.
• Brand and deliverability damage: if your domain appears in phishing links, URL reputation services and mail filters may start to distrust it.

Detection

Finding open redirects

• Code review and static analysis: search for every redirect sink (sendRedirect, Response.Redirect, redirect_to, header("Location"), res.redirect, assignments to window.location or location.href) and trace whether the destination comes from a request parameter, header, cookie or stored value.
• Dynamic testing: crawl for parameters whose values look like URLs or paths and check whether an external host is accepted, including encoded, protocol-relative and userinfo forms. CWE-601's example CVE-2020-11053, in an OAuth2 reverse proxy, involved a validation bypass using HTML-encoded whitespace, which shows why parser-level testing matters.
• OAuth configuration review: export every registered client and flag wildcard, prefix or HTTP redirect URIs, URIs on hosts you no longer control, and any generic redirect endpoint on a registered host.
• Bug bounty scope: decide explicitly how open redirect reports are triaged; downgrade standalone reports if you must, but treat any report on an OAuth redirect host or authorization server as high priority. See the Web Application Security Testing Guide.

Monitoring

• Log rejected redirect targets; Microsoft's ASP.NET Core guidance notes that logging URLs rejected by IsLocalUrl helps diagnose redirection attacks.
• Watch redirector endpoint traffic for spikes, unusual referrers and external destinations, and feed hits into phishing response.
• On authorization servers, alert on authorization requests with unregistered redirect URIs, bursts of error redirects and newly registered clients sending users straight to error paths.
• Use URL analysis and reputation in mail and web gateways (D3FEND D3-UA URL Analysis and D3-URA URL Reputation Analysis) that follows redirect chains rather than scoring only the first host.

Metrics

• Number of redirect sinks that accept external destinations without an allowlist (target: zero).
• Percentage of OAuth clients whose redirect URIs are all exact, HTTPS (or loopback for native apps) and on hosts you control.
• Rejected redirect attempts per week, by endpoint, as a signal of probing.
• Time to fix open redirect findings on authentication and OAuth hosts.
• Phishing reports involving your own domains as the first hop.

Prevention and hardening

Choosing a redirect design

Safe redirect rules for applications

• Use framework helpers: ASP.NET Core's LocalRedirect throws on non-local URLs and Url.IsLocalUrl lets code fall back to a safe page; a local URL has no host or authority and an absolute path. Django's LoginView and LogoutView take a success_url_allowed_hosts set for post-login and post-logout redirects.
• Parse, then compare: following OWASP, use a maintained URL parser that interprets URLs as browsers do; check scheme (HTTPS only), canonical host and effective port against an allowlist; constrain the path when only certain endpoints are allowed; reject userinfo and ambiguous input.
• Redirect to what you validated: build the final URL from the validated components; do not decode, normalise or append to it after the check.
• Cover client-side code: apply the same validation in single-page application routers, and allow only https: or relative destinations.
• Allowlist external hops: ASVS 5.0 V3.7.2 asks that automatic redirects to hosts outside the application's control go only to allowlisted destinations; V3.7.3 (Level 3) adds a notification with an option to cancel.
• Retire marketing redirectors on the main domain: move click tracking to signed links or a separate domain, and require a signature or server-side identifier for each destination.

OAuth redirect URI validation

This section focuses on the redirect-specific rules. For the wider protocol, see the OAuth 2.0 and OpenID Connect Guide and the OAuth 2.1, GNAP and FAPI Guide.

Malicious clients registered to abuse the authorization server's redirect behaviour overlap with consent phishing. See the Consent Phishing and Illicit OAuth Grants Guide.

Rollout

1. Inventory: list every redirect sink in code and every OAuth client registration, with an owner for each.
2. Prioritise: fix authentication, OAuth redirect URI hosts and authorization server error paths first, then marketing and general redirectors.
3. Observe: deploy validation in log-only mode for a short period to record which destinations real users reach.
4. Enforce: switch to blocking, sending rejected requests to a safe default page rather than an error, and migrate OAuth clients from wildcard to exact URIs one client at a time, with the owner testing each.
5. Roll back: keep the allowlist in configuration so a missed legitimate destination can be added without redeploying; never roll back to unvalidated redirects.
6. Prevent regression: add static analysis rules for redirect sinks, DAST checks and a redirect review step in client registration.

Small organisations usually benefit most from removing redirect parameters and using framework helpers. Large organisations and identity providers should centralise a redirect validation library and govern OAuth client registration as a security process.

Common failure patterns

• String checks instead of parsing: "starts with our domain" or "contains our domain" checks accept lookalike hosts, userinfo tricks and protocol-relative URLs.
• Validation followed by transformation: the URL is checked, then decoded or concatenated, so the browser receives something different from what was validated.
• Wildcard redirect URIs kept for convenience: dynamic preview or tenant environments registered as patterns, later abused through a lookalike match or a forgotten subdomain.
• A "harmless" redirector on the OAuth host: a generic continue or language endpoint on the same host as the redirect URI, closed as low severity in triage.
• Client-side redirects missed: server code is fixed while the single-page application router still reads the destination from the fragment.

Framework mapping

Practitioner checklist

• Inventory every redirect sink, server and client side, and every OAuth client redirect URI.
• Remove user-controlled redirects where possible; use identifiers mapped to server-side destinations elsewhere.
• Use framework local-redirect helpers for return-to-page logic after sign-in and sign-out.
• Validate external destinations by parsed scheme, host and port against an allowlist, and redirect to the validated value.
• Enforce exact redirect URI matching on authorization servers and remove wildcard, prefix and HTTP registrations.
• Confirm no open redirector exists on any host that serves an OAuth redirect URI.
• Require PKCE and the code response type, and set Referrer-Policy: no-referrer on redirect landing pages.
• Log rejected redirect targets and alert on unregistered redirect URIs at the authorization server.
• Triage open redirect reports on authentication and OAuth hosts as high priority.

Standards and references

• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• IETF: RFC 6749 The OAuth 2.0 Authorization Framework
• MITRE CWE: CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
• OWASP: Application Security Verification Standard 5.0
• OWASP: Unvalidated Redirects and Forwards Cheat Sheet
• OWASP: OAuth 2.0 Protocol Cheat Sheet
• Microsoft Learn: Prevent open redirect attacks in ASP.NET Core
• Microsoft Security: Widespread credential phishing campaign abuses open redirector links

Related NHI Mgmt Group resources: OAuth 2.0 and OpenID Connect Guide · Phishing Guide · AiTM Phishing Guide · Consent Phishing and Illicit OAuth Grants Guide · Web Application Attacks Guide