Open Redirect

What is Open Redirect?#

Open redirect is a vulnerability class under CWE-601 (URL Redirection to Untrusted Site) where an application accepts a URL in a request parameter and forwards the user's browser to that destination without validating the target is an authorized host. The redirect mechanism exists for legitimate reasons — sending a user back to the page they were trying to reach after login, or returning them to the referring application after an OAuth flow. The vulnerability arises when the destination URL is taken verbatim from attacker-controlled input.

The server-side form emits an HTTP 302 (or 301, 303, 307) with a Location header containing the attacker's URL. The browser follows it automatically. The client-side (DOM-based) form uses JavaScript: window.location = paramValue, document.location.href = req.query.next. Both fall under OWASP A01:2025 (Broken Access Control) because they allow users to be redirected outside the application's intended control boundary.

Open redirect sits at CVSS 6.1 in isolation — Medium, often rated Low in programs with high thresholds. The true severity multiplier comes from chaining. An open redirect on an OAuth authorization endpoint leaks the authorization code: Spring Security OAuth's CVE-2019-3778 is the textbook case, NVD scoring the code leak 6.5 while the account takeover it enables is what programs pay for (NVD, CVE-2019-3778). An open redirect on a domain in an SSRF allowlist is what Grafana's CVE-2025-4123 exploits — the redirect chained with a client path traversal to a frontend-plugin XSS and, with the Image Renderer plugin installed, a full-read SSRF, rated 7.6 (High) by Grafana (Grafana security advisory, 21 May 2025). CWE-601 is one of the most consistently reported classes in bug bounty programs: HackerOne's CWE discovery index counts 17,199 unique open redirect reports all time — seventh among the 25 weakness classes the index publishes — with 280 new reports in the twelve weeks to 15 October 2026, a 1% decline across the window (HackerOne CWE discovery index, retrieved 15 October 2026). In the CVE database the class is far rarer: the NDSS 2025 study "Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection" (Khodayari, Glauber and Pellegrino) measured open redirects at 1% of 237,470 CVE entries against 37% for XSS, and escalated more than 11.5% of the open redirects it found, on 38% of the affected sites, to XSS, CSRF or information leakage (NDSS Symposium 2025, paper 2025-523).

Mechanism#

The baseline pattern is a server-side parameter redirect:

GET /login?next=https://attacker.com HTTP/1.1
Host: trusted-bank.com
 
HTTP/1.1 302 Found
Location: https://attacker.com

The browser follows the Location header to attacker.com. The user sees trusted-bank.com in their address bar during the initial request — the trust is established before the redirect occurs.

sequenceDiagram
  participant U as User
  participant B as Browser
  participant S as trusted-bank.com
  participant A as attacker.com

  U->>B: Clicks phishing link to trusted-bank.com/login?next=https://attacker.com
  B->>S: GET /login?next=https://attacker.com
  Note over B: User sees trusted-bank.com in address bar
  S-->>B: 302 Location: https://attacker.com
  B->>A: GET / (browser follows redirect)
  A-->>B: Phishing login page
  Note over U: User believes they are on trusted-bank.com

The redirect chain unfolds in three steps:

1. User receives crafted URL — the initial domain is trusted (trusted-bank.com), so email filters, link previews, and browser security indicators show a legitimate domain.
2. Server issues 30x — the application reads req.query.next (or next, redirect, url, goto, return, callback) and passes it directly to res.redirect() without host validation.
3. Browser follows Location — the user lands on the attacker's server, which can serve a phishing page, initiate an OAuth phishing flow, or collect the Referer header containing session tokens.

The DOM-based variant skips the server round-trip:

// Vulnerable Express.js handler
app.get("/post-login", (req, res) => {
  const next = req.query.next;
  res.redirect(next);  // No validation — attacker controls destination
});

// Vulnerable client-side redirect
const params = new URLSearchParams(window.location.search);
const next = params.get("next");
window.location = next;  // Browser follows to attacker.com

Attack Variants#

URL Parser Differential Bypass#

The most technically interesting aspect of open redirect exploitation is the divergence between URL parsers. A backend validating a URL with Python's urllib.parse will reach different conclusions than the browser using the WHATWG URL standard:

from urllib.parse import urlparse
 
# Python sees this as a path with no netloc — "safe"
urlparse("\\evil.com").netloc  # Returns '' — Python thinks netloc is empty
urlparse("%09https://evil.com").netloc  # Returns '' — Python strips tab, sees no scheme
 
# But WHATWG (Chrome/Firefox) normalizes:
# \\evil.com → //evil.com → https://evil.com (browser follows)
# %09https://evil.com → https://evil.com (browser decodes tab, parses absolute)

Additional bypass payloads in active use (Diverto 2024 bypass list):

//attacker.com               # Protocol-relative — both slashes required
https:////attacker.com       # Multiple slashes — WHATWG strips extras
https:\attacker.com          # Backslash — WHATWG normalizes to /
https://trusted.com@evil.com # Userinfo — trusted.com is the username, evil.com is the host
https://trusted.com%40evil.com  # URL-encoded @
https://trusted.com.evil.com # Suffix abuse — validate full hostname, not endsWith
https://evil.com#trusted.com # Fragment — trusted.com is the fragment, not the host
%EF%BC%8E                    # Fullwidth period — Unicode normalization → .

Real-World Examples#

CVE-2025-4123 — Grafana (CVSS 6.1 (NVD)) Grafana's advisory (21 May 2025) describes an XSS built from two flaws: a client path traversal combined with an open redirect. The redirect sends a victim to a website that hosts a frontend plugin, which executes arbitrary JavaScript — no editor permissions required, and with anonymous access enabled the XSS fires without a session. Grafana rates it 7.6 (High, CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L) and shipped fixes in 10.4.18, 11.2.9, 11.3.6, 11.4.4, 11.5.4, 11.6.1 and 12.0.0 (+security-01 builds). With the Grafana Image Renderer plugin installed, the same redirect reaches a full-read SSRF; the default Content-Security-Policy (connect-src) blocks the XSS in a default deployment. NVD's own analysis of the same record is 6.1 (Medium) — the isolated-redirect view. CVE-2025-6023 repeated the pattern: an open redirect chained with path traversal to XSS, introduced in Grafana 11.5.0 and fixed in 11.3.8, 11.4.6, 11.5.6, 11.6.3 and 12.0.2 (+security-01 builds) (CNA Grafana, CVE-2025-6023, published 18 July 2025).

CVE-2025-69725 — go-chi RedirectSlashes (CVSS 4.7 Medium) The RedirectSlashes middleware in go-chi's router normalized path double-slashes: GET //evil.com was processed as a path needing normalization, yielding 302 Location: //evil.com. Browsers resolve protocol-relative URLs (//evil.com) against the current scheme — https://evil.com in production. The flaw was introduced in chi 5.2.2; any Go application with RedirectSlashes enabled and no Host validation was affected. CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N (CNA MITRE, CVE-2025-69725, published 19 February 2026).

CVE-2024-23832 — Mastodon (CVSS 9.8 (NVD)) Not an open redirect at all, and it belongs in this list for exactly that reason: Mastodon's flaw was insufficient origin validation, which let an attacker impersonate and take over any remote account (NVD, CVE-2024-23832, published 1 February 2024). GitHub's advisory rates confidentiality impact Low; NVD's primary metric says 9.8 with C:H. Two scorers, two readings of the same record — which is why every score in this article names its source.

CVE-2019-3778 — Spring Security OAuth (CVSS 6.5 Medium) The canonical open-redirect-to-code-leak case: versions 2.3 before 2.3.5, 2.2 before 2.2.4, 2.1 before 2.1.4 and 2.0 before 2.0.17 accepted a manipulated redirect_uri, causing the authorization server to redirect the resource owner user-agent to an attacker-controlled URI with the leaked authorization code (NVD, CVE-2019-3778, published 7 March 2019). NVD scores the leak 6.5 — the redirect itself is not what makes it dangerous, the code it hands over is.

Detection#

Manual Testing#

1. Enumerate redirect parameters across the application: next, url, redirect, redirect_uri, redirect_url, goto, target, dest, destination, return, returnTo, forward, link, continue, callback, r, u. Use gf redirect (tomnomnom/gf) against Wayback Machine data for historical coverage.
2. Submit an external domain as the parameter value: https://example.com first (to confirm the redirect mechanism works), then your Burp Collaborator or Interactsh URL.
3. Check the Location header in the response — does it contain your input verbatim? Does the browser follow it to the external domain?
4. For OAuth flows, inject an open redirect in the redirect_uri and observe whether the authorization code is appended to the crafted URL before the redirect.
5. Test bypass variants in order: //attacker.com, \attacker.com, %09https://attacker.com, https://attacker.com@trusted.com, https://trusted.com.attacker.com, https://attacker.com%00trusted.com.
6. Confirm false positive elimination: verify that Location: /dashboard and Location: https://target.com/path are NOT reported — these are same-origin redirects.

Automated Detection#

OpenRedireX — async fuzzer, sends 50+ bypass payloads per parameter:

echo "https://target.com/login?next=FUZZ" | openredirex -p /path/to/payloads.txt

nuclei — template-based scanner with CVE-specific detection:

nuclei -u https://target.com -t http/cves/2025/CVE-2025-4123.yaml

Dalfox v3.0+ — --open-redirect mode for parameter-level fuzzing:

dalfox url "https://target.com/login?next=1" --open-redirect

The key signal for automated detection is a 30x response where the Location header contains the submitted canary value — confirming user input is reflected into the redirect destination without normalization. DOM-based detection requires JavaScript rendering (headless browser) to observe window.location assignments.

BreachVex detects open redirects via out-of-band canary probes injected into discovered redirect parameters. A confirmed finding requires a 30x Location header containing the canary domain, or a DNS callback confirming server-side fetch. The scan applies eTLD+1 normalization and partner allowlist checks before emitting a finding.

Prevention#

Allowlist by Internal Key, Not URL String#

The most robust fix eliminates URL parameters entirely:

# BAD — user-controlled URL passed directly to redirect
from flask import request, redirect
 
@app.route("/login")
def login():
    next_url = request.args.get("next", "/dashboard")
    return redirect(next_url)  # Open redirect
 
# GOOD — opaque key maps to server-side destination
import secrets
import redis
 
@app.route("/login")
def login():
    # Store destination before initiating login
    state = secrets.token_urlsafe(32)
    redis_client.set(f"redirect:{state}", "/original-destination", ex=300)
    return redirect(f"/auth/start?state={state}")
 
@app.route("/auth/callback")
def callback():
    state = request.args.get("state", "")
    destination = redis_client.get(f"redirect:{state}") or b"/dashboard"
    return redirect(destination.decode())

Allowlist Hostname Validation (when URL parameter is required)#

# BAD — endsWith is bypassable via trusted.com.evil.com
from urllib.parse import urlparse
 
def is_safe_redirect(url: str) -> bool:
    parsed = urlparse(url)
    return parsed.netloc.endswith("trusted.com")  # VULNERABLE
 
# GOOD — exact hostname match after parsing
from urllib.parse import urlparse
 
ALLOWED_HOSTS = frozenset({"app.example.com", "dashboard.example.com"})
 
def is_safe_redirect(url: str) -> bool:
    if url.startswith("//") or "\\" in url:
        return False
    parsed = urlparse(url)
    # Reject empty scheme with non-empty netloc (protocol-relative after decode)
    if not parsed.scheme and parsed.netloc:
        return False
    if parsed.netloc and parsed.netloc not in ALLOWED_HOSTS:
        return False
    # Control character check
    if any(c in url for c in ["\r", "\n", "\t", "\x00"]):
        return False
    return True
 
# Force relative URL as safest fallback
def safe_redirect_url(url: str, fallback: str = "/dashboard") -> str:
    return url if is_safe_redirect(url) else fallback

// Node.js/Express — GOOD
const ALLOWED_HOSTS = new Set(["app.example.com", "dashboard.example.com"]);
 
function isSafeRedirect(url) {
  try {
    // Use WHATWG URL constructor — same parser as browsers
    const parsed = new URL(url, "https://app.example.com");
    return ALLOWED_HOSTS.has(parsed.hostname);
  } catch {
    // Relative URLs throw — allow them if they start with /
    return url.startsWith("/") && !url.startsWith("//");
  }
}
 
app.get("/redirect", (req, res) => {
  const next = req.query.next ?? "/home";
  res.redirect(isSafeRedirect(next) ? next : "/home");
});

OAuth redirect_uri — Exact Match Required#

# BAD — prefix matching (vulnerable to path traversal)
def validate_redirect_uri(requested: str, registered: str) -> bool:
    return requested.startswith(registered)  # VULNERABLE
 
# GOOD — exact string match per RFC 6749 §3.1.2
def validate_redirect_uri(requested: str, registered: str) -> bool:
    return requested == registered  # Exact match only — no prefix, no wildcard

Resources#

• OWASP Unvalidated Redirects and Forwards Cheat Sheet
• PortSwigger — Open Redirect Labs
• CWE-601: URL Redirection to Untrusted Site
• HackerOne CWE discovery — CWE-601 (retrieved 15 October 2026)
• Khodayari, Glauber & Pellegrino — "Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection", NDSS 2025
• RFC 6749 §3.1.2 — OAuth 2.0 Redirection Endpoint
• NVD — CVE-2019-3778 (Spring Security OAuth open redirect leaking an authorization code)
• Grafana security advisory — XSS in Frontend Plugins in Grafana (CVE-2025-4123, 21 May 2025)
• NVD — CVE-2025-6023 (Grafana open redirect chained with path traversal to XSS)
• NVD — CVE-2025-69725 (go-chi/chi RedirectSlashes open redirect)
• NVD — CVE-2024-23832 (Mastodon insufficient origin validation)