What Is an Open Redirect Vulnerability? How It Works and Why It Matters

The Vulnerability Hiding in Plain Sight

Most web applications have redirect functionality. You log in and get redirected to your dashboard. You click a link and get redirected through an analytics tracker. You reset your password and get redirected to the login page. Redirects are everywhere.

An open redirect vulnerability exists when an application uses user-supplied input to determine where to redirect the user — without validating that the destination is safe. An attacker can craft a URL on your legitimate domain that redirects visitors to any site they choose.

How an Open Redirect Works

Consider a login page that accepts a `next` parameter:

`https://yourcompany.com/login?next=/dashboard`

After successful login, the application reads the `next` parameter and redirects the user there. The intended behaviour is to send logged-in users to the page they originally requested.

The vulnerability appears when the application does not validate what `next` contains:

`https://yourcompany.com/login?next=https://evil.com/phishing-page`

If the application blindly redirects to whatever URL is in the `next` parameter, the user ends up on the attacker's site — and the URL they clicked started with your legitimate domain.

Why Attackers Use Open Redirects

The key is the trust that comes from seeing a familiar domain in the URL. When a user hovers over a link and sees `yourcompany.com` in the status bar, or clicks a link that starts with `yourcompany.com`, they assume they are going somewhere safe. An open redirect exploits that trust.

**Phishing amplification:** An attacker sends an email with a link to `yourcompany.com/login?next=https://attacker.com/fake-login`. The user sees a link to a site they recognise and trust. They click it, the application redirects them to the attacker's fake login page, and they enter their credentials — which the attacker captures. Because the initial URL was legitimate, spam filters and security tools are less likely to flag it.

**Credential harvesting chains:** Open redirects are frequently chained with other attack techniques. An attacker might use an open redirect to bypass a blocklist that prevents direct links to their infrastructure, routing traffic through a trusted domain first.

**Bypassing URL whitelists:** Some applications use URL whitelists to determine where to redirect users. An open redirect on a whitelisted domain can be used to bypass this protection and reach URLs that would otherwise be blocked.

Real Examples

Open redirect vulnerabilities have been found in major platforms. Google's many web properties have historically had open redirects, and security researchers have documented how these were used in large-scale phishing campaigns — attackers sending emails with google.com URLs that redirected to credential-harvesting pages.

A common pattern in UK e-commerce applications: the checkout flow redirects to a `return_url` parameter after payment processing. If the payment callback handler does not validate that `return_url` points to the same domain, an attacker can manipulate the URL to redirect users to an external site after checkout — potentially a fake "your order was confirmed" page that harvests additional information.

How to Detect Open Redirects

Manual testing involves looking for parameters in URLs that appear to control redirect destinations — `next`, `return`, `redirect`, `url`, `goto`, `dest`, `destination`, `forward`, `redirect_to`. Then testing whether arbitrary external URLs can be supplied:

- Appending `?next=https://evil.com` to the parameter - Encoding the URL: `?next=https%3A%2F%2Fevil.com` - Using protocol-relative URLs: `?next=//evil.com` - Using `@` syntax: `?next=https://yourcompany.com@evil.com`

Automated scanners test for open redirects by checking common parameter names and several bypass techniques. Yrzo AI's scanner includes open redirect detection as part of its 44-check suite.

How to Fix an Open Redirect

**Option 1 — Allowlist of valid destinations** The safest approach: only redirect to URLs that are on an explicit allowlist. If your application only ever needs to redirect to `/dashboard`, `/account`, and `/orders`, only allow those paths.

```python ALLOWED_REDIRECTS = {"/dashboard", "/account", "/orders"}

def safe_redirect(next_url): if next_url in ALLOWED_REDIRECTS: return redirect(next_url) return redirect("/dashboard") # default safe fallback ```

**Option 2 — Validate the destination is same-origin** If you need to support dynamic redirect destinations, validate that the destination URL uses the same scheme and host as your application. Reject anything that would take the user off your domain.

```python from urllib.parse import urlparse

def is_safe_redirect(url, host): parsed = urlparse(url) # Allow relative URLs (no scheme/host) and same-host absolute URLs return (not parsed.netloc) or (parsed.netloc == host) ```

**Option 3 — Use opaque redirect tokens** Instead of including the destination URL in the parameter, generate an opaque token that maps to a server-side destination. The token cannot be manipulated to point to an external site because the mapping is stored server-side.

**What not to do:** Do not attempt to block external URLs by checking for `http://` or `https://` prefixes. Attackers use protocol-relative URLs (`//evil.com`), path confusion (`//evil.com`), and encoding tricks (`%2F%2Fevil.com`) to bypass prefix-based checks.

Severity and Impact

Open redirects are typically rated Low to Medium severity on their own. CVSS scores usually land between 3.0 and 6.0. But the actual risk depends heavily on how the redirect is used — a redirect on a post-login flow is significantly more dangerous than one on a low-traffic static page, because attackers can combine it with phishing at scale.

Security teams sometimes underestimate open redirects because "the user ends up on another site — so what?" The answer is that when that other site is a perfect replica of your login page, and the user's browser URL bar showed your domain moments before, the phishing success rate is dramatically higher than a cold attack.

An automated scan that catches open redirects early — before attackers find them — costs far less than a phishing incident affecting your customers.