An open redirect vulnerability allows an attacker to craft a URL on your legitimate domain that redirects users to an arbitrary external website. The vulnerability is often rated as low to medium severity in isolation, but its real danger is as an enabler: phishing campaigns that use your trusted domain as a launchpad, OAuth token theft, and bypassing security tools that validate link destinations by domain.

How Open Redirects Work

Web applications commonly redirect users to a URL specified in a query parameter — after login, after a form submission, or when a session expires:

https://yoursite.com/login?next=/dashboard
https://yoursite.com/logout?redirect=/home
https://yoursite.com/click?url=https://partner.com/offer

If the application redirects to the value of next, redirect, or url without validation, an attacker can substitute:

https://yoursite.com/login?next=https://evil-phishing-site.com/fake-login

After authenticating on your legitimate site, the user is silently redirected to the attacker's site. From the user's perspective, they just logged in normally — they were on yoursite.com the whole time. The attacker's site can render a convincing "Your session expired, please re-enter your password" page.

Why Attackers Value Open Redirects

Phishing Credibility

Email security filters and user awareness training focus on the domain in a URL. A link to https://yourbank.com/login?next=https://harvester.attacker.com passes the domain check — it really does start with https://yourbank.com. The malicious destination is buried after the redirect parameter. Many users and email scanners will not notice.

OAuth Token Theft

OAuth 2.0 authorization codes and tokens are delivered to a redirect_uri parameter. If an OAuth provider accepts any registered redirect URI that starts with a base URL, and your application has an open redirect, an attacker can construct:

https://oauth.provider.com/authorize?
  client_id=yourapp&
  redirect_uri=https://yoursite.com/callback?next=https://attacker.com&
  response_type=code

The authorization code is sent to yoursite.com/callback, which then redirects to attacker.com — forwarding the code in the URL. The attacker exchanges the code for an access token.

Security Tool Bypass

URL reputation services, email link scanners, and browser safe browsing checks evaluate the initial URL's domain. An open redirect on a reputable domain can route through to a known-malicious destination that would otherwise be blocked.

Finding Open Redirects

Look for URL parameters with names like: next, redirect, redirect_uri, return, returnTo, url, goto, destination, target, link, forward.

Test by supplying an absolute URL to an external domain:

https://yoursite.com/login?next=https://google.com

If you are redirected to Google after interacting with the endpoint, an open redirect exists. Check the Location header in the response for redirects that happen server-side.

Prevention

Use an Allowlist of Valid Destinations

The most robust approach: only allow redirects to a predefined list of safe paths or domains.

SAFE_REDIRECT_PATHS = {'/dashboard', '/home', '/settings', '/profile'}

def safe_redirect(target):
    from urllib.parse import urlparse
    parsed = urlparse(target)
    # Only allow relative paths or paths from your own domain
    if parsed.netloc and parsed.netloc != 'yoursite.com':
        return redirect('/dashboard')  # Fallback
    if parsed.path not in SAFE_REDIRECT_PATHS:
        return redirect('/dashboard')
    return redirect(target)

Validate That the Target Is Relative or Same-Origin

If you need to redirect to arbitrary paths (not just a fixed list), validate that the target has no external domain component:

from urllib.parse import urlparse

def is_safe_redirect(target):
    parsed = urlparse(target)
    # Allow only relative URLs (no scheme, no netloc)
    return not parsed.netloc and not parsed.scheme

# Usage
next_url = request.args.get('next', '/dashboard')
if not is_safe_redirect(next_url):
    next_url = '/dashboard'
return redirect(next_url)

Be aware of edge cases: URLs like //evil.com have no scheme but do have a netloc — the above check handles this correctly because parsed.netloc would be evil.com.

Warn Users About External Redirects

For link-shortener or redirect services where external destinations are intentional, implement an interstitial page that warns users they are leaving your site and shows the destination URL. This eliminates the phishing vector entirely — the attacker's hidden destination is revealed.

Testing Your Application

Automated scanners test for open redirects by submitting external URLs to common redirect parameters and checking whether the Location response header points outside your domain. Manual testing is simple: find all redirect parameters in your application and test each one. Open redirects are consistently in the top findings of bug bounty programs — they are more common than most developers expect.