Open Redirect: Definition, Risks & Prevention

What Is an Open Redirect?

An open redirect is a redirect vulnerability in which a website accepts a user-controlled destination URL without adequately validating it. The site then sends the browser to that URL, even though the destination may belong to an unrelated or malicious domain.

For example, a legitimate site might provide a redirect endpoint such as:

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

If the application accepts any value for url, an attacker could replace it with a phishing address. The resulting link still begins with the trusted example.com domain, which may make it appear legitimate at first glance.

How Open Redirects Work

Websites use redirects for valid purposes, such as sending users to a page after login, forwarding tracking links, or returning users to the page they originally requested. The vulnerability occurs when the destination is controlled by the visitor and the application does not restrict where the redirect may go.

A vulnerable pattern may look conceptually like this:

redirect?next=https://attacker.example/login

The application reads the next parameter and redirects the browser without checking whether the destination is approved.

Attackers may also use URL formats, encoding, or confusing hostname syntax to evade weak filters. Checking only whether a string contains a trusted domain is not sufficient. For example, a check for example.com could be fooled by a hostname such as example.com.attacker.example.

Why Open Redirects Matter

An open redirect often does not directly give an attacker control of the affected website. Its main danger is abuse of the website's reputation and trusted domain.

Common consequences include:

• Phishing: A malicious link can begin with a familiar domain before redirecting to a fake login or payment page.
• Social engineering: Users may be more likely to click a link associated with a site they recognize.
• Security control bypass: Redirects may be used to get around allowlists or filters that trust the original domain.
• Token or referral leakage: In some situations, redirect chains can expose sensitive URL parameters to another site.
• Abuse of analytics and tracking links: Redirect endpoints can hide the real destination and make malicious campaigns harder to identify.

The practical severity depends on the application, the information included in the URL, the site's reputation, and whether the redirect can be combined with another vulnerability.

How to Prevent Open Redirects

The safest approach is to avoid accepting arbitrary external URLs when a redirect is not necessary. Where redirects are required, use one or more of these controls:

• Prefer a relative path such as /account instead of a complete external URL.
• Use an allowlist of approved destination hosts when external redirects are genuinely needed.
• Parse the URL with a reliable URL parser rather than relying on simple string matching.
• Validate the scheme and permit only expected schemes, normally https and possibly http where appropriate.
• Reject usernames, unexpected ports, encoded control characters, and ambiguous URL forms unless they are explicitly required.
• Store approved destinations as server-side identifiers instead of accepting raw URLs from users.
• Display an interstitial warning before sending users to an external domain when appropriate.
• Avoid placing sensitive tokens or session information in redirect URLs.

A common safe design is to accept a short destination key, such as account, and map it on the server to a known internal path. This prevents a user from substituting an arbitrary destination.

Open Redirect vs. Normal Redirect

A normal redirect is intentional and controlled by the application. For example, a site may always redirect /old-page to /new-page, or send a signed-in user to a fixed dashboard.

An open redirect is different because an outside party can influence the destination in a way the application did not intend. The presence of a redirect alone is not a vulnerability; the issue is insufficient control over where it leads.

What to Check During Review

When assessing a redirect endpoint, test whether changing parameters such as url, next, return, continue, or redirect allows navigation to an unrelated domain. Review both successful and failed validation cases, including encoded URLs and alternate hostname formats.

A redirect should be considered safe only when its destination is deliberately constrained and the validation applies consistently across all relevant code paths.