What Is Open Redirect?

Open redirect is a web application vulnerability that lets an attacker use a trusted site to send a user to a different, often malicious, destination. In practice, the application accepts a user-controlled URL and redirects the browser without properly validating where it is going.

On its own, an open redirect may not look severe. But in real attacks, it often helps phishing, fake login pages, and other social engineering schemes work better because the link starts on a domain the victim recognizes.

Open redirect definition

An open redirect happens when a website or application forwards a user to a destination supplied by a parameter such as next=, returnUrl=, redirect=, or url= without restricting that destination safely.

A simple example might look like this:

https://example.com/redirect?url=https://attacker-site.tld

If the application allows that value without validation, a user can click a trusted example.com link and end up on a malicious page.

How open redirect works

Redirects are common in normal web applications. They are often used after login, logout, form submission, or when moving users between pages or systems.

The problem starts when redirect behavior trusts user input too much.

Why developers use redirects

Redirects are often legitimate. Applications may use them to:

• return a user to the page they originally requested after login
• forward traffic from old URLs to new ones
• move users between related applications
• support campaign tracking links
• complete identity or authorization workflows

The issue is not redirection itself. The issue is allowing an attacker to control the destination.

A typical attack flow

A common open redirect attack works like this:

1. The attacker finds a redirect endpoint on a legitimate domain.
2. They craft a link that appears to start on a trusted site.
3. The victim clicks it because the domain looks familiar.
4. The application forwards the victim to an attacker-controlled page.
5. The attacker uses that page for credential theft, malware delivery, or another scam.

The redirect is usually not the final objective. It is the trust bridge that makes the next step more convincing.

Why attackers use open redirects

Attackers like open redirects because they can:

• make phishing links look more credible
• bypass simple domain-based user scrutiny
• chain trusted domains into social engineering campaigns
• support fake SSO or login flows
• hide the final destination until after the click

That is why security teams usually treat open redirect as more than a cosmetic issue.

Why open redirect matters

Open redirects can increase the success rate of phishing and identity attacks because users often judge a link by the first domain they see.

They are especially useful when chained with:

• phishing kits
• fake login pages
• OAuth consent scams
• token theft attempts
• malicious file delivery
• brand impersonation campaigns

In some cases, redirect flaws can also affect application logic directly, especially in authentication or authorization workflows where trust decisions depend on approved destinations.

For a related overview of phishing-driven attacks, see what is phishing.

Common causes of open redirect

Open redirects usually happen because redirect logic is implemented too loosely.

Accepting arbitrary external URLs

The most direct cause is allowing a user to supply any full URL as a redirect target.

Weak validation checks

Some applications try to validate destinations with fragile logic, such as checking whether the URL string contains the company name. Attackers can often bypass that with crafted domains or encoding tricks.

Mishandling relative paths and encoding

Redirect validation can also fail when developers do not normalize paths, encoded characters, or alternate URL formats correctly.

Overtrusting identity or marketing flows

Login systems, SSO handoffs, campaign links, and referral paths are common places where redirect behavior gets added quickly and reviewed lightly.

How to prevent open redirect

The safest approach is to avoid arbitrary user-controlled redirect destinations.

Good patterns include:

• allowing only a fixed set of approved destinations
• using internal route names instead of raw URLs
• permitting only relative internal paths where appropriate
• validating scheme, host, and path strictly
• normalizing input before comparison
• rejecting unknown external destinations by default

In most cases, an allowlist-based approach is much safer than trying to filter bad URLs.

If you are reviewing broader secure coding issues, our guide to what is sql injection covers another common web application flaw caused by unsafe input handling.

When you’ll encounter open redirect

You are most likely to encounter open redirect in these situations.

Application security testing

Open redirects often appear in:

• penetration tests
• bug bounty findings
• code reviews
• dynamic application testing
• OWASP-style assessments

They are easy to miss because the affected feature may seem routine.

Login and SSO workflows

Authentication systems often send users back to a requested page after sign-in. If those return paths are not tightly controlled, redirect abuse can show up in highly trusted parts of the application.

Marketing and tracking systems

Campaign tools, referral links, and analytics redirects often handle outbound destinations and can become open redirect points if validation is weak.

Phishing investigations

Incident responders frequently see open redirects when suspicious emails use a real corporate or vendor domain as the first step in a malicious link chain.

Final takeaway

Open redirect is a trust abuse issue. The application allows an attacker to use a legitimate domain to send users somewhere unsafe, which makes phishing and related attacks more believable.

It may not always be the most severe vulnerability in isolation, but in real-world attack chains, open redirect often provides exactly the trust boost an attacker needs.