Open Redirect Vulnerabilities:
How They Work and How to Fix Them

What Is an Open Redirect?

An open redirect occurs when a web application accepts a URL parameter to redirect the user after some action — login, logout, checkout — and forwards the user to that URL without validation. The simplest example:

# Intended use: redirect to internal page after login
https://example.com/login?next=/dashboard

# Attacker's URL: redirects to phishing site
https://example.com/login?next=https://evil.com/fake-login

The attack URL starts with https://example.com — it passes email security scanning, users see the legitimate domain in the link, and browser security indicators show nothing suspicious. The redirect happens silently after the user interacts with the legitimate page.

Attack Scenarios

• Credential phishing: Send users through a login page to establish trust, then redirect to a fake login form that captures their credentials (classic "your session expired, please log in again").
• Malware distribution: Redirect users to a drive-by download page, bypassing email and URL filtering that blocks direct links to malicious domains.
• OAuth token theft: Exploit the redirect_uri parameter in OAuth flows (see below).
• SSRF amplification: In server-side redirect implementations, redirect to internal network addresses.

Common Filter Bypass Techniques

If a developer checks that the redirect URL starts with /, attackers use:

# Protocol-relative URL — "//" is treated as external
//evil.com

# Slash bypass variants
\/evil.com
/\evil.com

# URL encoding
%2F%2Fevil.com

# Null byte injection (in older parsers)
/dashboard%00https://evil.com

# Starts with your domain but isn't yours
https://example.com.evil.com

OAuth Token Theft via Open Redirect

The most severe impact of open redirects occurs in OAuth flows. If an application has an open redirect and also uses OAuth, an attacker can chain them to steal authorization codes or access tokens:

1. Attacker crafts an authorization request with a valid redirect_uri pointing to your open redirect endpoint
2. Example: redirect_uri=https://example.com/redirect?next=https://evil.com
3. If the OAuth server allows this redirect_uri (it's on the trusted domain), the authorization code is appended and the user is sent to https://evil.com?code=AUTH_CODE
4. Attacker exchanges the stolen code for an access token

Prevention

from urllib.parse import urlparse

SAFE_PATHS = {"/dashboard", "/profile", "/settings"}

def safe_redirect(next_url: str) -> str:
    # Option 1: Path-only allowlist (best for post-login redirects)
    parsed = urlparse(next_url)
    if parsed.scheme or parsed.netloc:
        return "/dashboard"  # reject any absolute URL
    if parsed.path not in SAFE_PATHS:
        return "/dashboard"  # reject unknown paths
    return parsed.path

    # Option 2: Don't use URL parameters at all — use server-side session
    # Store intended destination in session before redirect to login
    # Retrieve from session after successful authentication

The cleanest solution: never accept a destination URL as a query parameter. Store the intended redirect destination in the server-side session before redirecting to login. After authentication, read the destination from the session and redirect there. The destination never passes through the URL bar.

Testing for Open Redirects

• Search your codebase for parameters named next, redirect, url, return, returnTo, goto, destination
• In your DAST tool, test redirect parameters with an out-of-scope URL and check the Location header in responses
• Use Burp Suite's active scanner redirect checks, or the OWASP ZAP redirect scanner