Open redirection

Sites often use HTTP or URL parameters to redirect users to a specified URL without any user action. While this behaviour can be useful, it can also cause open redirects, which happen when an attacker is able to manipulate the value of this parameter to redirect the user offsite.

  • Open redirects are generated due to an incorrect URL validation in the application.

  • The most common consequence is phishing.

  • In some cases, the behaviour depends on the browser used to interact with the application. It is because some methods used by the developers to create the redirections just work in a few browsers. Open redirects are most common in Internet Explorer.


  1. Search for redirect URL parameters. These might be vulnerable to parameter-based open redirect.

  2. Search for pages that perform referer-based redirects. These are candidates for a referer-based open redirect.

  3. Test the pages and parameters found for open redirects.

  4. If the server blocks the open redirect, try protection bypass techniques.

  5. Brainstorm ways of using the open redirect in other bug chains.

There are some redirections that are easy to detect – most redirections use a GET request. Others are a little more difficult to detect in simple view and need the use of the HTTP proxy to confirm them.

Look for redirect parameters

Start by searching for the parameters used for redirects:

Redirections using JavaScript:'')

Open your proxy while you browse the website. Then, in HTTP history, look for any parameter that contains absolute or relative URLs.

Also take note of the pages that do not contain redirect parameters in their URLs but still automatically redirect their users. These pages are candidates for referer-based open redirects. To find these pages, keep an eye out for 3XX response codes like 301 and 302. These response codes indicate a redirect.

Use Google Dorks

Google dorking is an efficient way to find redirect parameters. To look for redirect parameters on a target site, start by setting the site search term to your target site:

Then look for pages that contain URLs in their URL parameters, making use of %3D, the URL-encoded version of the equal sign (=):


Also try using %2F, the URL-encoded version of the slash (/) to get relative URLs:


And search for the names of common URL redirect parameters:


Test for parameter-based open redirects

Investigate the functionality of each redirect parameter found and test each one for an open redirect. Insert a random hostname, or a hostname you own, into the redirect parameters; then see if the site automatically redirects to the site specified.

Some sites will redirect to the destination site immediately, others require a user action first.

Test for referer-based open redirects

Set up a page on a domain you own and host this HTML page:

    <a href="">Click on this link!</a>

Replace the linked URL with the target page. Then reload and visit your HTML page. Click the link and see if you get redirected to your site automatically or after the required user interactions.

Bypassing protections

Sites prevent open redirects by validating the URL used to redirect the user, making the root cause of open redirects failed URL validation. And, URL validation is extremely difficult to get right.

Sometimes validators do not account for all the edge cases that can cause the browser to behave unexpectedly. In this case, try to bypass the protection by using a few strategies.

Modern browsers often autocorrect URLs that do not have the correct components, in order to correct mangled URLs caused by user typos.

As a common defense against open redirects, the URL validator often checks if the redirect URL starts with, contains, or ends with the site’s domain name. This type of protection can be bypassed by creating a subdomain or directory with the target’s domain name:

The validator might accept only URLs that both start and end with a domain listed on the allowlist. This URL satisfies both of these rules:

Or you could use the at symbol (@) to make the first the username portion of the URL:

Especially custom-built URL validators are prone to attacks like these, because developers did not consider all edge cases. Too agile maybe?

You can also manipulate the scheme portion of the URL to try to fool the validator.


Use the data: scheme to construct a base64-encoded redirect URL that evades the validator.

When validators validate URLs, or when browsers redirect users, they have to first find out what is contained in the URL by decoding any characters that are URL encoded. If there is any inconsistency between how the validator and browsers decode URLs, this can be exploited.

Try to double- or triple-URL-encode certain special characters (like the slash) in the payload. if the validator does not double-decode URLs, but the browser does, you can use a payload like this:

Non-ASCII characters (%ff is the character ÿ, a non-ASCII character):

The validator has determined that is the domain name, and attacker.comÿ is the subdomain name.

Sometimes browsers decode non-ASCII characters into question marks:

Another common scenario is that browsers will attempt to find a “most alike” character (the () here is %E2%95%B1):╱

You can also use character sets in other languages to bypass filters, like Unicode.

To defeat more-sophisticated URL validators, combine multiple strategies to bypass layered defenses, like:


Attackers could use open redirects by themselves to make their phishing attacks more credible. For example, they could send this URL in an email to a user:

Though this URL would first lead users to the legitimate website, it would redirect them to the attacker’s site after login. The attacker could host a fake login page on a malicious site that mirrors the legitimate site’s login page, and prompt the user to log in again. Believing they’ve entered an incorrect password, the user would provide their credentials to the attacker’s site. At this point, the attacker’s site could even redirect the user back to the legitimate site to keep the victim from realizing that their credentials were stolen.

An open redirect can help you bypass URL blocklists and allowlists:

This URL will pass even well-implemented URL validators, because the URL is technically still on the legitimate website. Open redirects can, therefore, help you maximize the impact of vulnerabilities like server-side request forgery (SSRF).

Open redirects can also be used to steal credentials and OAuth tokens. When a page redirects to another site, browsers will often include the originating URL as a referer HTTP request header. When the originating URL contains sensitive information (authentication tokens), attackers can induce an open redirect to steal the tokens via the referer header.

Portswigger lab writeups


Avoid dynamically setting redirection targets using data that originated from any untrusted source.

Force redirects to first go to a page that notify users they are redirected out of the website. The message should clearly display the destination and ask users to click on a link to confirm that they want to move to the new destination.