Key distinctionA redirect is not vulnerable merely because its destination changes. The weakness exists when an attacker can influence the destination beyond what the application intended. The practical risk then depends on where the redirect occurs and what security-sensitive process trusts it.
What Is an Open Redirect Vulnerability?
Web applications use redirects for legitimate reasons: returning a user to the page they requested before login, moving users after logout, sending customers to partner services, completing OAuth authentication, or navigating between application routes.
The security problem begins when the application accepts a redirect target from an untrusted source and treats that value as an authorized destination without enforcing an appropriate destination policy. This matches the core weakness described by both MITRE CWE-601 and the OWASP Unvalidated Redirects and Forwards Cheat Sheet: attacker-controlled input is allowed to determine a redirect destination that the application has not adequately restricted.
For example, an application might accept a parameter such as next, url, redirect, return, returnUrl, or redirect_uri. Those names are not vulnerabilities by themselves. They become security-relevant when changing the value allows the browser or server to leave the destinations the application intended to permit.
Open redirects belong to the wider family of website security vulnerabilities. Their defining property is attacker influence over a redirect destination rather than injection into an HTML, SQL, or operating-system command interpreter.
How Does an Open Redirect Work?
A useful way to understand open redirects is to trace the destination from its source to the final navigation. The vulnerability is usually created somewhere between receiving the attacker-controlled value and deciding whether that value is an acceptable destination.
- Source: the application receives a destination from a query parameter, form field, URL fragment, cookie, API response, authentication state, or another attacker-influenced source.
- Redirect decision: server-side or client-side code decides that navigation should occur.
- Parsing and validation: the application interprets the supplied destination and decides whether it is permitted.
- Redirect mechanism: an HTTP response, JavaScript API, application router, or another mechanism performs the redirect.
- Final destination: the browser reaches either an intended application location or an attacker-controlled destination.
The important security question is therefore not simply, “Does this parameter contain a URL?” It is, “Can attacker-controlled data cause the application to navigate outside the destinations this workflow is supposed to allow?”
Redirect security is a destination-control problemA strong implementation defines the destinations a feature actually needs and then permits only those destinations. Trying to identify every possible malicious URL is usually weaker than defining what is explicitly allowed.
Where Do Open Redirect Vulnerabilities Occur?
Open redirects can be implemented through different technologies. These mechanisms should not be confused with separate vulnerability classes: the same underlying weakness is still attacker control over an insufficiently restricted destination.
Server-Side HTTP Redirects
Server-side redirects commonly return a 3xx HTTP response containing a Location header. If application code inserts a user-controlled destination directly into that header without enforcing an approved destination policy, the response may redirect the browser to an arbitrary site.
Login, logout, payment, email verification, password-reset, tracking, and “continue to destination” endpoints are common places where this pattern appears.
Client-Side JavaScript Redirects
A redirect can also occur entirely in the browser. JavaScript may read data from location.search, location.hash, application state, browser storage, or an API response and then assign that value to a navigation API such as window.location or location.href.
The OWASP Web Security Testing Guide specifically covers client-side URL redirection and identifies browser navigation APIs such as window.location as relevant sinks during testing. The objective is to determine whether attacker-controlled URL or path data can cause navigation to an unintended external destination.
In this case, the server may never issue a 3xx response. Detection therefore requires observing browser-side behavior rather than checking only HTTP response headers.
Authentication, OAuth and SSO Redirects
Authentication systems rely heavily on redirects because users must often return to an application after signing in with an identity provider. These flows are more security-sensitive than ordinary navigation because authorization codes, access tokens, state values, or session context may be involved.
PortSwigger’s OAuth security guidance documents how weaknesses in redirect_uri validation can expose authorization codes or access tokens. It also describes scenarios where a callback accepted by an authorization server points to another page on an approved domain that itself contains an open redirect, allowing sensitive OAuth data to be forwarded to an external destination.
The current OAuth 2.0 Security Best Current Practice (RFC 9700) requires authorization servers to use exact string matching when comparing redirect URIs against pre-registered values, except for the defined localhost port exception for native applications. The same guidance states that OAuth clients and authorization servers must not expose open redirectors because they can facilitate phishing or leakage of authorization codes and access tokens.
Approved callback paths should also be reviewed for their own redirect behavior. Strict validation at the authorization server can be undermined if an accepted callback page immediately performs another unrestricted redirect.
Open Redirect Vulnerability Example
Consider an application that redirects users after login based on a query parameter:
GET /login?next=https://test.invalid/accountIf the application performs the redirect without checking whether the destination is permitted, a response might effectively behave like this:
HTTP/1.1 302 Found
Location: https://test.invalid/accountThe vulnerability is not the 302 response itself. The problem is that the requester was able to choose an external destination the application did not intend to trust.
An attacker can distribute a link beginning with the legitimate website’s domain. A victim may focus on that trusted hostname without realizing that the application will immediately redirect the browser somewhere else.
Real-World Open Redirect Example
A publicly disclosed HackerOne report involving Tumblr’s logout workflow provides a useful real-world example. The affected endpoint accepted a redirect_to parameter that controlled where the user was sent after logout, and specially structured URL input could cause navigation to an external destination.
The important lesson is not a particular bypass string. It is that URL validation should operate on a standards-aware parsed and normalized destination rather than relying on visual inspection, substring matching, or assumptions about how unusual URL syntax will be interpreted.
The case also shows why apparently simple open redirects still appear in mature applications: URL syntax can contain user-information delimiters, backslashes, encoding, unusual hostname structures, and other representations that behave differently when validation logic and the final navigation component interpret them inconsistently.
Why Are Open Redirect Vulnerabilities Dangerous?
A basic open redirect generally has less direct technical impact than a vulnerability such as remote code execution or SQL injection. Its real severity depends on what additional trust the redirect can abuse.
Phishing and Trusted-Link Abuse
The classic use is phishing. The attacker distributes a URL on a legitimate domain but manipulates its redirect parameter so the victim is later sent to an attacker-controlled page. The trusted first domain can make the link appear more credible in emails, messages, or other interfaces.
This abuse is one reason the OWASP redirect guidance warns that unvalidated redirects can make phishing links appear more trustworthy: the visible link begins with a legitimate application’s domain before navigation leaves that site.
OAuth and Authentication Chains
An open redirect becomes more serious when an authentication system accepts an insufficiently restricted callback or when an approved redirect path contains another open redirect. Depending on the exact OAuth flow and configuration, this can contribute to authorization-code or access-token leakage.
This does not mean every open redirect automatically compromises OAuth. The impact exists only when the surrounding authentication flow provides the additional conditions required for the chain.
SSRF Filter Bypass
Open redirects can also become part of a Server-Side Request Forgery (SSRF) chain. A server-side feature may approve the first URL but then follow an HTTP redirect to a destination that was never validated.
This is not merely theoretical. PortSwigger demonstrates an SSRF scenario in which an application restricts the original server-side request but follows an open redirect to a destination the original filter would otherwise block. The security lesson is that validating only the first destination may be insufficient when a server-side HTTP client automatically follows redirects.
The distinction is who follows the redirect. In a normal open-redirect phishing scenario, the victim’s browser navigates to the external destination. In an SSRF chain, a server-side HTTP client follows the redirect, potentially reaching resources available to the server but not to the external attacker.
Dangerous URL Schemes and Script Execution
Some poorly implemented redirect mechanisms do more than allow navigation to an external HTTPS destination. If a browser context accepts a dangerous URL scheme and interprets it as executable content, the finding may cross into a different vulnerability such as JavaScript injection or cross-site scripting.
That behavior should be classified according to what is actually demonstrated. An ordinary open redirect and executable script injection are related findings, but they are not interchangeable vulnerability labels.
Are Open Redirect Vulnerabilities Always High Severity?
No. Severity should be based on demonstrated impact rather than the vulnerability name alone.
| Scenario | Typical Security Meaning | Why Context Matters |
|---|---|---|
| Standalone external redirect | Primarily phishing or reputation risk | Usually requires a victim to follow the crafted link |
| Redirect inside login or logout flow | More convincing phishing opportunity | The victim already expects navigation around authentication |
| OAuth redirect chain | May contribute to code or token leakage | Impact depends on redirect URI validation and the OAuth flow |
| Open redirect used by SSRF | May bypass destination filtering | The server may follow the redirect into a prohibited network location |
| Redirect permits executable schemes | May become script injection or XSS | The resulting vulnerability should be assessed by the behavior actually achieved |
This distinction is particularly important in bug-bounty triage. A standalone redirect may receive relatively low priority or fall outside a particular program’s reward scope, while the same weakness can become materially more important when it enables another vulnerability.
HackerOne’s platform standards discuss this type of vulnerability chain. Their guidance uses an SSRF finding that depends on a known open redirect as an example where the earlier redirect finding should be reconsidered in light of the combined impact.
How to Find an Open Redirect Vulnerability
Testing should only be performed against applications you own or have explicit authorization to assess. The objective is to determine whether attacker-influenced data can move a redirect outside the destinations allowed by the application.
- Identify redirect functionality. Look at login, logout, callback, password-reset, checkout, tracking, SSO, and navigation workflows.
- Locate destination inputs. Parameters such as
next,url,redirect,redirectTo,return,returnUrl,return_to,continue,destination,redirect_uri, andRelayStatemay influence navigation, although the parameter name alone proves nothing. - Use a controlled external destination. Replace the expected value with a harmless domain under your control or a reserved testing destination.
- Observe the redirect mechanism. Check both HTTP 3xx responses and browser-side JavaScript navigation.
- Confirm the final destination. Determine whether the application actually leaves its intended origin rather than merely reflecting the supplied string.
- Test authenticated workflows where authorized. Some redirects appear only after login, logout, checkout, OAuth consent, SSO, or another state change.
- Document context. Record whether the finding is standalone or can affect authentication, tokens, server-side fetches, access control, or another security boundary.
For a broader manual assessment workflow, see ScanTitan’s guide to checking a website for vulnerabilities manually.
Reflection is not confirmationSeeing an external URL echoed in HTML or an HTTP response does not by itself prove open redirection. Confirm that the browser, server, or application router actually uses the attacker-controlled value as the navigation destination.
Can Vulnerability Scanners Detect Open Redirects?
Automated security tools can detect many open redirects, particularly when the redirect is directly controlled by an HTTP parameter and produces observable navigation. Coverage becomes less reliable when the redirect depends on authentication, complex JavaScript, multiple application states, SSO, or a security-sensitive OAuth workflow.
| Method | Useful For | Important Limitation |
|---|---|---|
| DAST | Testing redirect parameters and observing HTTP responses or resulting navigation | Coverage depends on crawling, parameter discovery and authentication |
| Browser-aware DAST | Client-side redirects, SPAs and JavaScript navigation | Complex application state and OAuth flows may still need human review |
| SAST | Tracing untrusted data toward redirect APIs in application code | A suspicious data flow may be protected by runtime validation |
| Manual testing | Validation behavior, authentication context and vulnerability chains | Slower and dependent on tester skill |
A website vulnerability scanner can provide repeatable runtime coverage across web application inputs, while browser-aware testing is particularly relevant to JavaScript-driven applications. Complex OAuth, SSO, or chained-impact cases may still require manual investigation.
Authenticated workflows also matter. If the redirect only appears after login, an external crawler that never reaches that state cannot test it. ScanTitan’s guide to authenticated vs unauthenticated scanning explains why coverage changes once the scanner can access application state behind authentication.
How to Fix an Open Redirect Vulnerability
The strongest fix is to reduce how much control the requester has over the destination. The OWASP Unvalidated Redirects and Forwards Cheat Sheet recommends avoiding user-controlled destination URLs when possible, mapping short names or IDs to server-side destinations, and using allowlists when dynamic destinations are genuinely required.
The general principle is to define what the application is allowed to redirect to rather than trying to maintain a list of every destination that might be malicious.
1. Prefer Fixed or Mapped Redirect Destinations
If a workflow only needs a small number of destinations, do not accept a complete URL from the browser. Accept a logical identifier and map it to a destination stored by the application.
const destinations = {
account: "/account",
billing: "/billing",
dashboard: "/dashboard"
};
const target = destinations[req.query.next] || "/dashboard";
return redirect(target);The requester selects a known option rather than defining a new destination. This removes much of the ambiguity involved in parsing and validating arbitrary URLs.
2. Restrict Redirects to Internal Destinations When Possible
If the business flow only needs navigation inside the current site, external URLs should not be accepted at all. Parse the supplied value and verify that its final normalized origin remains the application’s own origin before navigation occurs.
Checking only whether a string contains the company domain is not sufficient because URL syntax can contain usernames, subdomains, encoding, backslashes, and other structures that make superficial string comparisons unreliable.
3. Parse URLs Before Making Security Decisions
Use the platform’s maintained URL parser and make the security decision against the parsed destination. Avoid regular expressions, string concatenation, or substring matching as the primary URL parser.
The same parsed representation used for validation should correspond as closely as possible to what the navigation or HTTP library will later interpret. A validation layer and a redirect component that disagree about the meaning of the same URL can create bypass conditions.
Why URL parsing mattersRedirect validation should operate on a parsed and normalized URL rather than on superficial string patterns. Differences in how malformed or unusual URLs are interpreted can cause an apparently strict hostname check to authorize a destination that the browser or HTTP client ultimately resolves differently.
A real-world example appeared in the official Express.js open-redirect security advisory GHSA-rv95-896h-c2vc. The advisory illustrates why applications should parse user-provided redirect values with a proper URL parser before applying destination checks or passing them to redirect functionality.
4. Use an Exact Allowlist When External Redirects Are Required
Some applications legitimately redirect to partner domains or separate services. In that case, maintain a narrow allowlist of approved schemes, hosts, origins, and, where appropriate, paths.
Prefer exact parsed-host or origin comparison over tests such as “hostname contains example.com”. A hostname such as example.com.attacker.invalid contains the trusted string but is not the trusted domain.
Applications should also log rejected redirect attempts where practical. Repeated requests containing unexpected external hosts, malformed URLs, unusual schemes, or failed destination validation can help security teams identify probing and detect redirect-control regressions. Avoid logging complete URLs when they may contain authorization codes, access tokens, session identifiers, or other secrets.
5. Open Redirect Vulnerability Fix in JavaScript
The following client-side pattern is unsafe when the next value can be controlled by an attacker:
const params = new URLSearchParams(window.location.search);
const next = params.get("next");
if (next) {
window.location.href = next;
}A safer implementation parses the destination relative to the expected origin and falls back when the normalized origin is not allowed:
const params = new URLSearchParams(window.location.search);
const next = params.get("next");
const fallback = "/dashboard";
function safeInternalDestination(value) {
if (!value) return fallback;
try {
const target = new URL(value, window.location.origin);
if (target.origin !== window.location.origin) {
return fallback;
}
return target.pathname + target.search + target.hash;
} catch {
return fallback;
}
}
window.location.assign(safeInternalDestination(next));If the application needs only a few routes, mapping identifiers to fixed internal paths is stronger still. If legitimate external domains are required, compare the parsed origin or hostname against an explicit allowlist rather than allowing every syntactically valid URL.
6. Validate OAuth Redirect URIs Strictly
OAuth redirect URI validation should follow the protocol and the identity provider’s supported registration model. The OAuth 2.0 Security Best Current Practice requires exact string matching against pre-registered redirect URIs in the relevant authorization-server comparison, apart from the specified localhost exception for native applications.
Applications should therefore avoid treating a user-provided callback as trusted merely because it shares a prefix, suffix, or familiar domain string with an approved destination.
Approved callback paths should also be inspected for secondary redirects. A strict authorization-server check can still be weakened if the approved page contains another unrestricted redirect that forwards authorization data elsewhere.
7. Use an External-Redirect Warning When Arbitrary Destinations Are Intentional
Some products intentionally allow users to follow arbitrary external links. If unrestricted external navigation is part of the product’s design, an intermediate warning page can clearly show the destination and require the user to confirm that they are leaving the site.
OWASP lists this type of interstitial page as one possible defensive measure when external destinations genuinely need to be supported. It is different from silently accepting an unrestricted redirect parameter during a sensitive workflow such as login or OAuth authorization.
Common Open Redirect Validation Mistakes
Many incomplete fixes attempt to recognize a safe-looking string rather than enforcing the destination that the URL parser will actually use.
| Weak Approach | Why It Is Fragile | Stronger Approach |
|---|---|---|
| Check whether the URL contains the trusted domain | An attacker-controlled hostname can contain the trusted string | Parse the URL and compare the normalized origin or hostname exactly |
| Block a few known malicious domains | The attacker can use another domain | Allow only the destinations required by the feature |
| Accept any URL that begins with HTTPS | HTTPS says nothing about whether the destination is trusted | Validate both scheme and destination |
| Use regex as the URL parser | URL syntax and normalization contain many edge cases | Use a maintained standards-aware URL parser |
| Validate only the first destination | The allowed page may redirect again | Review redirect chains where the workflow follows multiple destinations |
| Validate only in frontend JavaScript | Server-side redirect requests can bypass frontend checks | Enforce the policy in the trusted component that performs the redirect |
| Allow any subdomain using a loose string check | A visually similar or attacker-controlled hostname may satisfy the text comparison | Parse the hostname and apply an explicit host or subdomain policy |
Open Redirect vs SSRF: What Is the Difference?
Both vulnerabilities can involve attacker influence over a URL, but the component making the important request is different.
| Question | Open Redirect | SSRF |
|---|---|---|
| Who normally follows the attacker-influenced destination? | The user’s browser | The application server or backend service |
| Primary security concern | Untrusted browser navigation and exploit chains | Abuse of server-side network access |
| Typical standalone impact | Phishing or external redirection | Access to unintended internal or external resources |
| Can the vulnerabilities be chained? | Yes. A server-side request feature may approve the initial URL and then follow an open redirect to a destination that the original validation would have blocked. | |
The distinction matters during testing. Seeing a browser navigate to another website demonstrates open-redirection behavior. Proving SSRF requires evidence that the server itself made the attacker-influenced request.
Open Redirect Vulnerability FAQ
What is an open redirect vulnerability?
An open redirect vulnerability occurs when attacker-controlled input can make an application redirect a user to a destination outside the locations the application intended to permit. MITRE classifies the weakness as CWE-601.
Is open redirect in the OWASP Top 10?
At the CWE mapping level, yes. In the OWASP Top 10:2025, CWE-601 URL Redirection to Untrusted Site (‘Open Redirect’) is included among the CWEs mapped to A01:2025 Broken Access Control.
How do you find an open redirect vulnerability?
Identify functionality that performs redirects, determine which values influence the destination, replace those values with a controlled external destination during authorized testing, and verify whether the browser or application actually navigates outside the intended destination set.
Can a vulnerability scanner detect open redirects?
Yes. Many directly observable open redirects can be detected using DAST. Browser-aware scanning is useful for JavaScript redirects, while authenticated, multi-step, OAuth, or SSO workflows may require additional application context or manual testing.
Are open redirects always low severity?
No. A standalone redirect is often relatively low severity, but impact can increase when the redirect contributes to OAuth credential leakage, an SSRF filter bypass, script execution, authentication abuse, or another vulnerability chain.
Are open redirects accepted on HackerOne?
Acceptance and bounty eligibility depend on each program’s policy and the demonstrated impact. HackerOne’s platform standards emphasize evaluating vulnerability chains by their overall impact and specifically use an SSRF finding that depends on a known open redirect as an example where the significance of the original redirect should be reconsidered.
How do you fix an open redirect in JavaScript?
Do not pass attacker-controlled strings directly to navigation APIs. Prefer fixed internal destinations or logical route identifiers. When dynamic URLs are necessary, parse the value with the platform URL parser and enforce the expected normalized origin or an explicit allowlist before navigation.
What parameters are commonly associated with open redirects?
Redirect functionality may use names such as next, url, redirect, redirectTo, returnUrl, return_to, destination, redirect_uri, or RelayState. A parameter name alone does not indicate a vulnerability; the destination must actually be insufficiently restricted.
What is the difference between an open redirect and SSRF?
An open redirect normally causes the user’s browser to navigate to an unintended destination. SSRF causes a server-side application to send an unintended request. An open redirect can sometimes be chained with SSRF when the server validates the first destination but follows a redirect to a prohibited second destination.
