Category: Attack Techniques
Open Redirect
Also known as: Unvalidated Redirect, Unvalidated Forward, URL Redirection Vulnerability
Simply put
An open redirect is a security flaw in a web application that allows an attacker to manipulate a redirect or forwarding function to send users to an external, potentially malicious website. Because the redirect originates from a trusted domain, users may not notice they are being sent somewhere harmful. This type of vulnerability is commonly exploited in phishing attacks.
Formal definition
An open redirect vulnerability occurs when a web application accepts user-supplied input, typically via a URL parameter, to construct a redirect or forward target without sufficient validation or allowlist enforcement. An attacker can craft a link hosted on a trusted domain that, when followed, redirects the victim to an attacker-controlled URL. This is typically exploited to lend credibility to phishing campaigns, bypass referrer-based access controls, or chain with other vulnerabilities. The vulnerability is rooted in the server-side or client-side redirect logic consuming unvalidated external input rather than resolving destinations against a permitted set of targets.
Why it matters
Open redirect vulnerabilities are frequently exploited as a force multiplier in phishing campaigns. Because the initial link originates from a trusted, recognizable domain, users and email security filters are less likely to flag it as suspicious. The attacker effectively borrows the reputation of a legitimate organization to deliver victims to a malicious destination, increasing the likelihood that the target will click the link and proceed without suspicion.
Who it's relevant to
Web Application Developers
Developers who implement authentication flows, post-login routing, marketing redirects, or any feature that constructs a redirect destination from request parameters are directly responsible for introducing or preventing this vulnerability. The correct mitigation is to avoid using user-supplied input as a redirect target when possible, and when a redirect parameter is necessary, to validate it strictly against an allowlist of permitted internal paths or domains rather than relying on prefix checks or substring matching.
Application Security Engineers and Penetration Testers
Security testers must identify open redirect vulnerabilities during assessments by probing redirect and forward parameters with external URLs and encoding variations. Static analysis tools may flag potentially dangerous redirect calls but typically cannot determine at the code level whether the destination is adequately constrained without understanding runtime input sources and validation logic. Dynamic testing and manual review are generally necessary to confirm exploitability and assess bypass potential through encoding or protocol tricks.
Security Operations and Incident Response Teams
SOC analysts and incident responders may encounter open redirects as components of phishing campaigns or as enabling steps in larger attack chains. Recognizing that a malicious link uses a trusted domain as a redirect hop is important for accurate triage, since automated tools may initially rate such links as lower risk due to the reputable origin domain. Threat intelligence workflows should account for the possibility that known-good domains may be weaponized through open redirect vulnerabilities.
Product and Risk Managers
Product owners and risk managers should understand that open redirect vulnerabilities, while often categorized as medium severity in isolation, can materially elevate the effectiveness of phishing attacks against customers and employees. The reputational risk of a trusted domain being used to redirect users to malicious sites may exceed the direct technical impact, and this consideration should inform prioritization decisions during vulnerability remediation cycles.
Inside Open Redirect
User-Controlled Redirect Parameter
A URL parameter, header value, or form field supplied by the user that the application accepts and uses to determine the destination of a redirect response, typically without sufficient validation.
HTTP Redirect Response
A server-issued HTTP response (commonly 301, 302, 303, or 307) whose Location header is populated with a destination URL derived from user-supplied input, causing the browser to navigate to that destination.
Allowlist of Permitted Destinations
A defined set of approved URLs, domains, or paths that the application permits as valid redirect targets, used as a control to prevent navigation to arbitrary external locations.
Phishing Vector
The exploitation path by which an attacker crafts a link using a trusted domain as the base while embedding a malicious destination, leveraging user trust in the originating domain to lend credibility to the redirect.
URL Validation Logic
The server-side or client-side code responsible for parsing and evaluating a candidate redirect destination, which may be bypassed through encoding tricks, protocol variations, or parser inconsistencies if not implemented carefully.
Bypass Techniques
Methods attackers use to circumvent insufficient redirect validation, including URL encoding, double encoding, protocol-relative URLs, subdomain manipulation, and parser-differential inputs that cause the validation logic and the browser to interpret the URL differently.
Common questions
Answers to the questions practitioners most commonly ask about Open Redirect.
Is an open redirect really a serious vulnerability, or is it just a low-severity informational finding?
Open redirects are frequently underestimated, but they carry meaningful risk when chained with other techniques. Attackers typically use them to lend legitimacy to phishing URLs, bypassing user suspicion because the initial domain in the link belongs to a trusted site. They may also be used to circumvent security controls that allowlist redirect destinations. Severity depends on context, but dismissing open redirects as purely informational overlooks their role as an enabler in multi-stage attacks.
Does validating that a URL is well-formed or that it uses HTTPS protect against open redirect abuse?
No. Validating URL format or enforcing HTTPS does not prevent open redirect exploitation. An attacker-controlled destination can be a well-formed HTTPS URL pointing to a malicious site. Effective mitigation requires validating the destination against an allowlist of permitted domains or paths, not simply checking structural properties of the URL.
What is the most reliable way to prevent open redirects in a web application?
The most reliable approach is to avoid accepting arbitrary redirect destinations from user-supplied input entirely. Where redirects must be dynamic, use an allowlist of permitted destination URLs or domains and reject any value not on the list. An alternative pattern is to use indirect references, mapping user-supplied tokens to server-side destination values, so the actual URL is never controlled by the user.
How can automated scanners and code review tools detect open redirect vulnerabilities?
Static analysis tools can identify locations in code where user-supplied input flows into redirect functions or HTTP Location headers without sanitization, flagging potential open redirect sinks. However, static tools typically cannot determine at the code level whether runtime validation, allowlisting, or framework-level controls are actually enforced, which may produce false positives. Dynamic scanners can exercise redirect parameters during testing and observe whether arbitrary destinations are followed, but they may miss redirects that are conditionally triggered or that depend on specific application state.
Should open redirect findings in third-party or framework components be treated differently from those in application code?
Yes, in most cases. Open redirects in third-party libraries or framework components may be outside the application team's direct control and may require version upgrades, patches, or compensating controls at the application layer, such as wrapping redirect logic with allowlist validation before passing values to the component. Tracking these findings through dependency management and vulnerability management processes is appropriate, rather than treating them identically to defects in first-party code.
Are there cases where open redirect behavior is intentional and acceptable?
Yes. Some application flows legitimately redirect users to external destinations, such as OAuth authorization endpoints, affiliate links, or federated login providers. In these cases, the destination is typically either hardcoded, drawn from a server-side configuration, or validated against a maintained allowlist of trusted domains. The distinction between acceptable and vulnerable behavior is whether the destination can be arbitrarily controlled by user-supplied input at runtime. Intentional external redirects should be explicitly documented and reviewed to confirm that user input does not influence the destination in an uncontrolled way.
Common misconceptions
Open redirects are low-severity issues and can be deprioritized without meaningful risk.
While open redirects may not directly expose data or execute code, they are frequently chained with other vulnerabilities such as OAuth token theft, credential phishing, and SSRF escalation. Their severity depends heavily on application context and what the redirect can be combined with, making blanket deprioritization inappropriate.
Validating that the redirect URL contains the application's domain name is sufficient to prevent open redirects.
Simple string-based domain checks are commonly bypassed using techniques such as subdomain manipulation (e.g., evil.com?trusted.com), URL encoding, or protocol-relative URLs. Robust validation requires strict parsing of the URL structure and comparison against an explicit allowlist of approved destinations, not substring matching.
Static analysis tools can reliably detect all open redirect vulnerabilities in an application.
Static analysis can identify code patterns where user-supplied input flows into redirect functions without apparent validation, but it typically produces false positives where validation exists but is not recognized by the tool, and false negatives where validation is present but bypassable only at runtime. Confirming exploitability and assessing bypass potential generally requires dynamic testing or manual review.
Best practices
Avoid using user-supplied input to construct redirect destinations entirely where possible. Instead, map user-provided tokens or identifiers to server-side stored URLs, so the actual destination is never exposed to or controlled by the user.
Where redirect parameters are necessary, validate the destination against an explicit server-side allowlist of approved absolute URLs or approved domains, using strict URL parsing rather than substring or contains checks.
When redirecting to relative paths within the same application, enforce that the destination is a relative path and does not include a scheme or host component, preventing escape to external domains.
Apply URL normalization and decoding before validation to ensure that encoded or obfuscated inputs resolve to their true form prior to any allowlist comparison, closing common encoding-based bypass paths.
Include open redirect scenarios in dynamic application security testing and manual penetration testing, as static analysis alone is insufficient to confirm exploitability or identify validation bypasses that depend on runtime URL parsing behavior.
When an open redirect cannot be eliminated, present users with an interstitial warning page that displays the destination URL and requires explicit confirmation before proceeding, reducing the effectiveness of phishing attempts that rely on the redirect being transparent.