Open Redirect Vulnerabilities: Why They Matter More Than You Think

An open redirect lets an attacker craft a link on your domain that sends users to a site of their choice. On its own it is often rated low severity. Combined with OAuth or SSO flows, it can lead to account takeover.

What an open redirect looks like

https://app.example.com/login?next=https://evil.example

After login, the application redirects to whatever next contains. The victim sees a trusted domain in the link, logs in, and lands on the attacker's page, which may show a fake "session expired, log in again" form.

Why it can be serious

Phishing credibility

Links that start with your real domain pass casual inspection and some email filters.

OAuth and SSO token theft

Many OAuth flows send the authorisation code or token to a redirect_uri. If the identity provider allows any path on your domain, and your domain has an open redirect, an attacker can chain them:

1. The attacker sets redirect_uri to your open redirect endpoint.
2. The identity provider sends the code to your domain, which is allowed.
3. Your open redirect forwards the request, including the code or token in the URL fragment or query, to the attacker.

This chain has been the basis of many high-severity bug bounty reports.

Bypassing allowlists

Other security controls, such as SSRF protections that allow your own domain, can be bypassed by redirecting through an open redirect.

Common validation bypasses

Developers often validate redirects with string checks that fail against:

• https://example.com.evil.example, which starts with the allowed domain.
• https://evil.example/?example.com, which contains it.
• //evil.example, a protocol-relative URL.
• /\evil.example, interpreted by some browsers as a host.
• https:evil.example and other malformed forms.
• javascript: URLs, which become XSS rather than a redirect.

How to implement safe redirects

1. Prefer relative paths only. Accept next=/dashboard, and reject anything that does not start with a single / followed by a non-slash character.
2. Or use an allowlist of destinations, mapped by key: next=billing redirects to a fixed URL.
3. Parse URLs properly with a URL parser and compare the parsed host exactly against an allowlist.
4. Show an interstitial for external destinations: "You are leaving example.com."
5. Register exact OAuth redirect URIs with your identity provider, not wildcards.

function safeNext(next) {
  return typeof next === "string" && /^\/(?!\/|\\)/.test(next) ? next : "/";
}

Testing for open redirects

SecurityInfinity agents test redirect parameters with bypass variants, check whether redirects chain with OAuth flows, and report the realistic severity. Start free.

Frequently asked questions

Do bug bounty programmes accept open redirects?

Many rate standalone open redirects as low or out of scope, but accept them when chained into token theft or another high-impact issue.

Are redirects after logout risky?

Yes, the same risks apply. Validate every redirect parameter consistently.

Is a meta refresh or JavaScript redirect also an open redirect?

Yes. Any mechanism that sends users to an attacker-controlled destination counts, and JavaScript redirects can additionally lead to XSS.