What is open redirect: risks and prevention

Open redirect is a web vulnerability in which an application sends the user's browser to a destination URL taken directly from a controllable parameter, without verifying that the destination belongs to a set of trusted sites. The standard catalogues it as CWE-601 (URL Redirection to Untrusted Site) and it is also known as unvalidated redirects and forwards. On its own it rarely compromises server data, which is why it tends to be undervalued in reports, but it is an extraordinarily useful building block for an attacker: it lends the reputation of a legitimate domain to a link that ends up on hostile infrastructure, and in authentication flows it can become the link that leaks full session tokens.

The essentials: open redirect abuses the trust that users and filtering systems place in a known domain. Its high risk appears when it is chained with phishing or with OAuth, where an unvalidated redirect allows exfiltration of authorization codes and access tokens. The correct defense is not a blocklist of bad domains, but a strict allowlist of permitted destinations, or better still, avoiding entirely that the destination travels as a URL in the parameter.

What open redirect is and why it is underestimated

The vulnerable pattern is born from a legitimate and very widespread feature: after signing in, after confirming an action or after leaving a payment gateway, the application wants to return the user to the page where they were. To remember that destination, many implementations store it in a URL parameter. Common names are ?next=, ?url=, ?redirect=, ?return=, ?returnUrl=, ?continue=, ?dest=, ?destination=, ?checkout_url= and, in federated flows, ?redirect_uri= or the SAML RelayState.

The flaw appears when the server takes that value and issues the redirect without checking the destination. A request as innocent as https://trustedapp.tld/login?next=/dashboard works just as well with https://trustedapp.tld/login?next=https://attacker.tld, and the browser lands on the attacker's site having started from a trusted domain. The reason it is underestimated is that the scanner flags a low severity and the developer sees no immediate data theft. That analysis ignores the real value of the bug: it lies not in what it does on its own, but in what it enables when combined with social engineering or with authorization protocols.

How it works: types of redirect

It helps to distinguish where the redirect materialises, because it changes both exploitation and defense.

Server-side redirect (Location header)

This is the classic variant. The backend responds with a 3xx code and a Location header built from the parameter:

GET /login?next=https://attacker.tld HTTP/1.1
Host: trustedapp.tld

HTTP/1.1 302 Found
Location: https://attacker.tld

It is detected with a simple header inspection, for example curl -I "https://trustedapp.tld/login?next=https://attacker.tld", observing whether the Location reflects the external domain unfiltered.

Client-side redirect (DOM-based)

Here the destination is processed by JavaScript in the browser, typically with window.location, location.href, location.assign() or location.replace() fed from location.search or the # fragment. This variant is DOM-based and does not always leave a trace on the server, which makes it harder to detect with tools that only look at HTTP responses. It also opens an additional door: if the code assigns to location a value with a javascript: or data: scheme, the open redirect can escalate to script execution on the domain, that is, a DOM-based XSS. Less frequent forms include a dynamically generated <meta http-equiv="refresh"> tag and Refresh headers.

Open redirect as a phishing weapon

The most common use is phishing. An email or message containing https://login.known-brand.tld/redir?url=https://known-brand.tld.attacker.tld/verify gets past the first human filter: the initial domain is real, it matches the brand and it appears in the status bar on hover. It also gets past many automated filters, because email gateways and proxies usually keep reputation lists per domain, and the starting domain is clean. The victim trusts the point of origin, does not notice the jump and lands on a cloned credential page.

This vector amplifies the campaigns described in our guide on how to avoid phishing, and it explains why an apparently minor finding deserves a fix: every open redirector on a corporate domain is a free amplifier for whoever impersonates the organisation.

OAuth token theft: the critical impact

Where open redirect stops being a nuisance and becomes serious is in OAuth 2.0 and OpenID Connect. The authorization code flow depends on a redirect_uri parameter that tells the authorization server where to return the code or the token. The standard requires that destination to be validated against the values registered by the client, precisely because it is a natural target.

The problem arises when redirect_uri validation is lax (for example, checking only that the domain matches) and an open redirect exists on that same domain. The attacker registers or requests a redirect_uri pointing to the legitimate client's open redirector; the authorization server accepts it because the host is on the allowlist; and after the victim authenticates, the authorization code or the access token travels toward the redirector, which in turn forwards it to the attacker's server, frequently exposed in the query string or the fragment and visible in the Referer header. This class of chaining was publicly documented as covert redirect in 2014 and remains valid. The current OAuth security guidance, RFC 9700 (OAuth 2.0 Security Best Current Practice), together with the considerations in RFC 6749, recommends exact string comparison for redirect_uri, prohibition of wildcards and use of PKCE, measures that close this abuse. If you work with tokens in your APIs, it is also worth reviewing our article on JWT security, because the token stolen through this route is usually a JWT with the whole session inside.

Bypass techniques against weak validation

Many applications try to defend themselves with fragile checks that an attacker breaks with URL variations. These are the techniques a pentester tries systematically:

• Protocol-relative URL: //attacker.tld. The browser interprets it as absolute toward that host, but a naive filter that only rejects strings starting with http lets it through.
• Userinfo abuse: https://trustedapp.tld@attacker.tld. A validator looking for the substring trustedapp.tld finds it, but the real host is attacker.tld.
• Backslash confusion: https:/\attacker.tld, /\/attacker.tld or \/\/attacker.tld. Browsers normalise backslashes to forward slashes, while many server parsers do not, creating an exploitable divergence.
• Misleading prefixes and suffixes: https://attacker.tld/trustedapp.tld, https://trustedapp.tld.attacker.tld or https://trustedapp.tld.attacker.tld/. The trusted domain appears in the string, but it is not the effective host.
• Encoding and control characters: %2F%2Fattacker.tld, double encoding, tabs or line breaks inserted to break regular expressions.
• IDN and Unicode homographs that visually imitate the legitimate domain.

The common denominator is a difference of interpretation (parser differential) between the component that validates the URL and the one that finally uses it. This same class of discrepancy is behind a series of Spring Framework advisories from 2024, identified as CVE-2024-22243 and CVE-2024-22262, where URL parsing in UriComponentsBuilder could be abused for open redirect and SSRF. That is why validation through a blocklist or a homemade regex is a losing battle.

How to prevent open redirect

Defense is ordered from the most robust to the most fragile:

1. Do not accept URLs as the destination. The safest option is indirection: instead of receiving a URL, receive a short identifier or token (?next=dashboard) that the server translates into a path through an internal map. The attacker cannot inject an arbitrary host because the host never travels in the parameter.
2. Force relative destinations. If the application only needs to return to one of its own pages, accept exclusively paths that start with a single slash and reject any value containing //, /\, a scheme or an @ character. Discard the host entirely and always prepend the server's own origin.
3. Strict allowlist of destinations. When the business requires redirecting to specific external domains (for example, payment gateways), parse the URL with a robust library, extract the host and compare it by exact match against a short list of permitted domains. Never by contains, startsWith or endsWith.
4. In OAuth, exact comparison of redirect_uri, with no wildcards or partial domain matches, plus PKCE on every public client.
5. Intermediate warning page for legitimate external exits, informing the user that they are leaving the domain before the redirect completes, as major search engines do.

As complementary layers, it is advisable to mark outbound links with rel="noopener noreferrer" so as not to leak the Referer, and to apply a Content Security Policy that limits navigation destinations where feasible. These measures do not replace destination validation, they reinforce it.

How to test open redirect in an audit

In a web audit, the usual flow begins by discovering candidate parameters. Tools such as Arjun or ParamSpider help enumerate hidden parameter names, and the Burp Suite interceptor lets you mark every point where a URL or a path travels to the server. Then a controlled domain (a canary) is injected into each suspicious parameter and the response is observed: a Location header or a client-side redirect pointing to the canary confirms the finding.

To automate the fuzzing of bypass lists, testers use ffuf and nuclei, which includes specific open redirect templates, as well as dedicated scanners such as Oralyzer. Manual confirmation remains essential in the DOM-based variant, where you have to review the JavaScript that assigns to location and check whether it accepts dangerous schemes. As part of the OWASP review, this control maps to WSTG-CLNT-04 (Testing for Client-side URL Redirect) in the Web Security Testing Guide.

Fit with OWASP and standards

Open redirect had its own entry in the OWASP Top 10 of 2013 as A10 (Unvalidated Redirects and Forwards) and disappeared as a standalone category in later editions due to its lower relative prevalence, not because it stopped existing. Today it is assessed within the discipline of input validation and the control of authentication flows, and it appears recurrently in bug bounty programs precisely because of its ability to chain. Its canonical identifier remains CWE-601, and handling it is part of any serious review alongside the rest of the catalogue, as covered in the most common web vulnerabilities of 2025.

Frequently asked questions

Is open redirect a severe or a minor vulnerability?

It depends on the context. Isolated and toward a destination without credentials, its severity is low. Chained with phishing on a brand domain or with a loosely validated OAuth flow, it becomes a high risk because it enables theft of credentials and session tokens. Severity is set by the use, not by the mechanics.

Is it enough to block URLs starting with http?

No. That filter breaks with //attacker.tld, with https:/\attacker.tld or with the @ trick in the userinfo. Any defense based on rejecting specific patterns (blocklist) loses against the variations of URL encoding and syntax. The correct solution is an allowlist of destinations or avoiding the URL in the parameter entirely.

What is the difference between open redirect and SSRF?

In open redirect, the party that makes the request to the malicious destination is the victim's browser, on the client side. In SSRF the party that makes it is the server itself, on the backend side, reaching internal resources. They share the idea of an unvalidated destination, but the impact and the defense differ.

How exactly does open redirect affect OAuth?

If the authorization server validates redirect_uri only by domain and an open redirector exists on that domain, the attacker gets the authorization code or the token forwarded to their server through the redirect. The mitigation is exact comparison of redirect_uri, prohibition of wildcards and PKCE, as RFC 9700 recommends.

Do modern frameworks protect by default?

Some offer aids, such as redirect helpers that force relative paths, but many accept absolute URLs without objection if the developer passes them. Effective protection depends on using those helpers correctly and on validating the destination, not on assuming the framework does it by itself.

Related resources

• What is CSRF: cross-site request forgery
• What is XSS: cross-site scripting
• What is SSRF: server-side request forgery
• JWT security: vulnerabilities and best practices
• How to avoid phishing
• Web and mobile application security audit

Auditing open redirect and web vulnerabilities with Secra

At Secra we treat open redirect not as a filler finding, but as what it is: an enabler of targeted phishing and of token theft in authentication flows. Our web audits, aligned with the OWASP Top 10 and the Web Security Testing Guide, enumerate every redirect parameter, systematically test bypass techniques, review the DOM-based variant in the application's JavaScript and verify redirect_uri validation in your OAuth and OpenID Connect flows. We deliver findings prioritised by real impact, reproducible test cases and concrete remediation recommendations for your stack. If you need to confirm that no domain in your organisation lends its reputation to an attacker, write to us through this page and we will plan a tailored audit.