Open Redirect

Open-redirect reports cluster around naive redirect parameter handling: server takes user-controlled ?url=, ?return_to=, ?redirect=, ?next=, ?goto=, ?dest=, ?continue= and Locations to it without scheme/host validation. Bypass tricks: protocol-relative //evil.com, encoded \evil.com, CRLF in HostAuthorization regex, fragment confusion https://target/path#@evil.com, userinfo https://allowed@evil.com, OAuth state-parameter manipulation. Tab-nabbing also reported (target=_blank without rel=noopener). Frequently chained with phishing or post-auth XSS where the redirect URL becomes a javascript: scheme.

• Login / SSO / OAuth callback URLs (return_to, next, redirect_uri, state)
• Email confirmation / unsubscribe links
• Payment-gateway return URLs
• Custom URL shorteners
• Post-action redirects (after-form-submit, after-logout)
• Password-reset success redirects
• Tabnabbing-prone external links in user content

• Submit ?url=https://evil.com and observe redirect
• Use protocol-relative ?url=//evil.com``
• Use backslash ?url=\\evil.com (browsers normalize backslash to slash)
• Use fragment trick ?url=https://target/#@evil.com to confuse parsers
• Use userinfo ?url=https://allowed.com@evil.com``
• Use CRLF / encoded CR ?url=ja%0d%0avascript:alert(1)``
• Use unicode confusable hosts (Punycode) and IDN tricks
• OAuth state replay across users
• Tabnabbing via window.opener.location.replace from external link

• https://evil.com
• //evil.com
• \\evil.com
• https://allowed.com@evil.com
• https://target/#@evil.com
• https://target/redirect?url=//evil.com
• javascript:alert(1)
• ja%0d%0avascript:alert(1)
• data:text/html,<script>alert(1)</script>
• https://evil.com%23.allowed.com

The canonical probe is straightforward: replace the candidate redirect parameter with an attacker-controlled URL and check whether the Location header points externally. When that fails outright, a bypass library covering //, \, @, #, CRLF, encoded variants, and confusable-host tricks catches redirects that a naive scheme check misses. A browser-driven check, navigating with a poisoned URL and watching for location.replace or location.href mutations in client-side JavaScript, catches redirects that only happen through DOM manipulation rather than a server-sent Location header. On OAuth and SSO paths that carry a state parameter, capturing that state and replaying it across two separate sessions tests for state-parameter reuse. Finally, auditing every external link in the page for a missing rel=noopener or rel=noreferrer catches tabnabbing risk, which is a related but distinct issue from a server-side redirect.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Some 'open redirects' are intentional - newsletter unsubscribe links and CDN edge redirects often allow arbitrary destinations by design.
• Flag with low/medium severity unless the redirect appears in a privileged context (login flow, OAuth callback).
• Tabnabbing alone is informational; only meaningful on user-controlled-content pages.

Manual Testing Methodology

Here is a systematic approach to identifying Open Redirect vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Open Redirect specifically, set every redirect-controlling parameter to an external domain in several encodings (https://evil.com, //evil.com, /\evil.com, https:/evil.com, a URL-encoded variant) since redirect validation is frequently protocol- or slash-count-sensitive.

Compare the response against your baseline, looking specifically for a 3xx response with a Location header pointing at the attacker-controlled domain, or client-side navigation (window.location) to it — confirm the browser actually leaves the trusted origin, not just that the parameter was accepted.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Open Redirect, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Open redirect vulnerabilities let attackers abuse a trusted domain to send users to a malicious site. The direct impact looks limited at first glance, but open redirects are a genuinely powerful phishing tool: victims see a legitimate domain in the address bar right up until the moment they're redirected, which makes the social engineering that follows much more convincing.

In OAuth and SSO flows specifically, open redirects become critical. An attacker who can redirect the callback URL can steal authorization codes or tokens outright, turning what looks like a low-severity finding into a full account takeover chain. Several high-profile OAuth bypass attacks have relied on exactly this pattern.

Bug bounty programs increasingly accept open redirect reports specifically when the researcher can demonstrate a practical attack chain rather than just the redirect on its own.

Prevention and Secure Coding

Preventing Open Redirect takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Allowlist redirect targets. Validate the redirect destination against an allowlist of relative paths or known, explicitly-approved domains — never accept an arbitrary URL from a query parameter and redirect to it directly.

Prefer relative paths internally. Where the redirect only ever needs to go somewhere within the same application, express it as a path, not a full URL, which removes the ability to redirect off-domain by construction.

Confirmation page for external redirects. If redirecting to an external, user-influenced destination is a real product requirement, interstitially show the destination and require explicit confirmation before following it.

Treat OAuth/SSO redirect URIs as security-critical config. Register exact, non-wildcard redirect URIs with the identity provider rather than a permissive pattern — this is the specific control that prevents an open redirect from escalating into token theft.