JavaScript-based Redirect

What is JavaScript-based Open Redirect?#

DOM-based open redirect is a client-side variant of CWE-601 where the redirect logic executes entirely in the browser, driven by JavaScript reading user-controlled data from the DOM. Unlike server-side open redirect — which emits a 30x HTTP response — DOM-based redirect produces no observable HTTP response change. The browser navigates to the attacker-controlled URL directly from JavaScript without a server round-trip.

This variant falls under OWASP A01:2021 (Broken Access Control) and maps to DOM-based XSS precursor patterns in terms of data flow: source → taint propagation → sink. The OWASP Testing Guide covers it as WSTG-CLNT-004. Automated vulnerability scanners that do not execute JavaScript will consistently miss this class — coverage requires headless browser instrumentation or manual review of client-side code.

The attack surface is any JavaScript that reads from a URL-related source (query string, hash fragment, referrer, postMessage, window.name) and writes to a navigation sink without validating the destination host.

Mechanism#

The taint flow structure mirrors server-side open redirect but operates in the browser's JavaScript engine:

The hash-based variant is particularly dangerous because the URL fragment is never sent to the server — it exists only in the browser and in client-side logs. Server-side detection, logging, and WAF rules cannot observe it.

// VULNERABLE — hash-based DOM redirect
// URL: https://trusted-app.com/dashboard#https://evil.com/capture
 
const hashValue = window.location.hash.slice(1);  // "https://evil.com/capture"
if (hashValue) {
  window.location = hashValue;  // Open redirect — no validation
}

// VULNERABLE — query parameter DOM redirect
const params = new URLSearchParams(window.location.search);
const next = params.get("next");
if (next) {
  window.location.href = next;  // No host check — direct navigation
}

// VULNERABLE — postMessage-based redirect
window.addEventListener("message", (event) => {
  // Missing: if (event.origin !== "https://trusted-origin.com") return;
  const data = JSON.parse(event.data);
  if (data.redirect) {
    window.location.replace(data.redirect);  // Attacker sends {redirect: "https://evil.com"}
  }
});

Attack Variants#

CVE-2024-43788 — webpack-dev-server#

webpack-dev-server included a development error overlay that read redirect destinations from URL parameters without validation. An attacker could craft a URL pointing to the development server (running on localhost:8080 or a CI/CD environment) that triggered a DOM-based redirect to a phishing page. This affected only development environments but targeted developers — a valuable credential-theft attack surface given developers' access to production secrets.

// Simplified representation of the webpack-dev-server error overlay vulnerability
// Reads redirect destination from URL parameter without WHATWG validation
const overlayParams = new URLSearchParams(window.location.search);
const redirectTarget = overlayParams.get("redirect");
if (redirectTarget) {
  window.location.href = redirectTarget;  // Vulnerable line
}

Real-World Examples#

CVE-2024-43788 — webpack-dev-server (CVSS 6.1) webpack-dev-server's development error overlay contained DOM-based open redirect via unvalidated URL parameters. Any development environment serving webpack-dev-server was vulnerable to developer-targeted phishing attacks. Fixed in webpack-dev-server 5.1.0 by validating redirect destinations against an allowlist.

Hash Fragment Redirect Pattern (Widespread) Single-page applications that use location.hash for post-authentication redirect (/login#/intended-path) routinely contain DOM-based open redirects when the hash is not validated before being passed to the router or window.location. React and Vue applications that handle external redirects by checking if (next.startsWith("/")) are typically vulnerable to the //evil.com bypass — since //evil.com starts with /, the check passes.

postMessage Redirect in Embedded Widgets (Multiple HackerOne Reports) Embedded chat widgets, payment iframes, and third-party integrations frequently use postMessage for cross-frame communication. When the message handler navigates based on message data without origin validation, any page that embeds the widget can trigger a redirect on the parent page. Bounties in the $500-$2,000 range for this pattern on major platforms.

Detection#

Manual Testing#

1. Search JavaScript source for navigation sinks: window.location, document.location, location.href, location.hash, location.replace, location.assign, window.open.
2. Trace data flow backward from each sink — what sources feed into these assignments? Query string, hash, referrer, postMessage, window.name?
3. Inject a canary string (REDIRECT_CANARY) into each URL parameter and fragment. Use Burp DOM Invader to trace whether the canary reaches a navigation sink.
4. For hash-based: navigate to https://target.com/page#REDIRECT_CANARY and check whether the browser navigates or whether window.location.hash is assigned to a navigation sink.
5. For postMessage: use a test page that sends window.opener.postMessage({redirect: "https://canary.example.com"}, "*") and check for navigation.

Automated Detection#

# Burp Suite DOM Invader — inject canary string, trace to navigation sinks
# Enable DOM Invader via Burp's browser, navigate the application
 
# semgrep — static analysis for JavaScript navigation sinks
semgrep --config=auto --lang=javascript \
  --pattern='window.location = $VAR' \
  --pattern='location.href = $VAR' \
  src/
 
# dalfox v3+ with DOM redirect mode
dalfox url "https://target.com/page" --open-redirect --mining-dom
 
# nuclei DOM-based redirect templates
nuclei -u https://target.com -t javascript/ -tags redirect

The key challenge for automated detection: the vulnerability requires JavaScript execution. Static analysis can find potential source-to-sink paths; confirming exploitability requires headless browser navigation with network monitoring.

BreachVex detects DOM-based redirects by executing JavaScript in an instrumented headless browser and monitoring navigation events. A confirmed finding requires the browser to actually navigate to the canary URL, not just string matching in source code.

Prevention#

Allowlist Validation Before Navigation Sinks#

// GOOD — validate using WHATWG URL constructor before any navigation
const ALLOWED_HOSTS = new Set(["app.example.com", "dashboard.example.com"]);
 
function safeNavigate(url) {
  if (!url) return;
  // Allow relative paths (single slash prefix, not protocol-relative)
  if (url.startsWith("/") && !url.startsWith("//")) {
    window.location.href = url;
    return;
  }
  try {
    const parsed = new URL(url);  // WHATWG — same parser as browser
    if (ALLOWED_HOSTS.has(parsed.hostname)) {
      window.location.href = url;
    } else {
      window.location.href = "/dashboard";  // Safe fallback
    }
  } catch {
    window.location.href = "/dashboard";  // Invalid URL — fallback
  }
}
 
// Usage — replaces window.location = next
const next = new URLSearchParams(window.location.search).get("next");
safeNavigate(next);

Reject Hash-Based External Navigation#

// GOOD — use hash only for same-origin SPA routing
const hash = window.location.hash.slice(1);
if (hash && hash.startsWith("/")) {
  // Internal SPA route — safe
  router.push(hash);
} else if (hash) {
  // External URL in hash — reject
  console.warn("Blocked external hash redirect:", hash);
}

Fix postMessage Handlers#

// BAD — accepts messages from any origin
window.addEventListener("message", (event) => {
  const data = JSON.parse(event.data);
  window.location.href = data.redirect;  // Vulnerable
});
 
// GOOD — validate origin before processing
const TRUSTED_ORIGINS = new Set(["https://partner.example.com"]);
 
window.addEventListener("message", (event) => {
  if (!TRUSTED_ORIGINS.has(event.origin)) {
    return;  // Ignore messages from untrusted origins
  }
  const data = JSON.parse(event.data);
  if (data.redirect) {
    safeNavigate(data.redirect);  // Use the validated safeNavigate function
  }
});

Resources#

• PortSwigger DOM-Based Open Redirection
• OWASP WSTG-CLNT-004 Testing for DOM-based Redirect
• CWE-601: URL Redirection to Untrusted Site
• PortSwigger DOM Invader Documentation