Open Redirect

Loaning your domain's credibility to a phishing scam.

The idea

An Open Redirect vulnerability occurs when an application takes a URL from user input (like a query parameter) and redirects the user to that URL without validating it first. Attackers exploit this by sending victims a link that *looks* like it points to a trustworthy site (e.g., your bank), but immediately redirects them to a malicious phishing site.

How it works (Strict Whitelisting)

The `next` or `return_to` parameter is incredibly common in login flows. To prevent Open Redirects, you must ensure the destination is either a relative path (staying on your domain) or strictly matches a hardcoded whitelist of allowed external domains.

# VULNERABLE: Open Redirect
@app.route("/login")
def login():
    # ... check credentials ...
    
    # DANGER: Blindly redirecting to whatever the user provided
    next_url = request.args.get("next")
    return redirect(next_url)

# SECURE: Validating the redirect
@app.route("/login")
def login():
    # ... check credentials ...
    
    next_url = request.args.get("next")
    # Only allow relative paths (starts with single slash, not double slash //)
    if next_url and next_url.startswith("/") and not next_url.startswith("//"):
        return redirect(next_url)
    
    return redirect("/dashboard") # Safe default

Watch out for

• Double Slashes (`//`): A developer might check `if url.startswith("/")` thinking it forces a relative path. But `//hacker.com` is a valid protocol-relative URL! The browser will redirect to `http://hacker.com`.
• Token Leakage: Open redirects are often chained with OAuth vulnerabilities. If an OAuth flow redirects to an attacker-controlled site, the victim's secret OAuth token might be appended to the URL and stolen.

Worked example

An attacker sends a phishing email: "Your account is locked. Please login to unlock it: `https://chase.com/login?next=http://chase-security-update.com`". The victim checks the domain, sees `chase.com`, and clicks it. Chase logs them in, then blindly redirects them to `chase-security-update.com` (which the attacker owns). The attacker's site looks identical to Chase and asks the user for their Social Security Number.

Check yourself

Why is filtering out `http://` and `https://` from the `next` parameter not enough to prevent Open Redirects?