Open redirect is a type of web application security issue that allows attackers to use your business reputation to make phishing attacks more effective. If you allow open redirects, an attacker can send a phishing email that contains a link with your domain name and the victim will be redirected from your web server to the attacker’s site.

Note that open redirects were included as a vulnerability in the OWASP Top 10 list in 2013 (A10 Unvalidated Redirects and Forwards).

What Is a Redirect

A redirect happens when the website or web application changes the URL that is accessed in the client (usually external – internal redirects are usually called forwards). There are several ways to do this from the back-end. Usually, redirects are made by sending specific HTTP headers to the client but you can also create redirects, for example, using JavaScript code.

What Is Open Redirection

An open redirect vulnerability exists when the destination of the redirect is provided by the client and it is not filtered or validated. Here are some examples of safe redirects and unsafe redirects:

  • If the legitimate website redirects the client to a fixed URL, it is a safe redirect.
  • If the legitimate website safely constructs the redirect URL based on parameters provided by the user, it is a safe redirect.
  • If the legitimate website constructs the redirect URL based on parameters provided by the user but does not sufficiently validate/filter input, it is an unsafe redirect (the attacker may manipulate the input).
  • If the legitimate website allows the user to specify the destination redirect URL, it is an unsafe redirect (open redirect).

In general, developers who use dynamic redirects (based on data from the client) must treat such data as untrusted input. If not, the attacker will redirect the browser to a malicious site and use your domain name to fool the victim.

For example, if your domain is, the attacker may create the following URL:

The attacker may then send this URL as part of a phishing attempt to redirect the victim to a malicious website The attacker would be hoping that at the beginning will have a trustworthy appearance and make them fall for the phishing scam.

An Example of Open Redirection

The following simple PHP code creates an open redirect:

$redirect = $_GET['url'];  header("Location: " . $redirect);

This is an open redirection vulnerability because the attacker may supply a malicious website URL in the url parameter value of the GET request and this target URL will then be sent as the Location header, redirecting the client to a malicious web page.

Consequences of Open Redirection Vulnerabilities

If you have an open redirection vulnerability, it makes many other attacks possible:

  • Phishing: The most obvious way to use an open redirect is to steer the victim away from the original site to a site that looks the same, steal user credentials, and then return to the vulnerable website as if nothing happened.
  • Cross-site Scripting (XSS): If the redirect allows the use of data: or javascript: protocols and the client supports such protocols in redirects, it makes it possible for the attacker to perform an XSS attack.
  • Server-Side Request Forgery (SSRF): Open redirects may be used to evade SSRF filters.
  • Content-Security-Policy bypassing: If you use CSP to protect against XSS and one of the whitelisted domains has an open redirect, this vulnerability may be used to bypass CSP.
  • CRLF Injection: If the redirection parameter allows line breaks, the attacker may try to perform response header splitting.

How To Prevent Open Redirects

The safest way to prevent open redirection vulnerabilities is not to use any redirections in your web applications. If this is not possible, you can attempt the following approaches:

  • Use a list of fixed destination pages. Store their full URLs in a database table and call them using identifiers as request parameters, not the URLs themselves. For example, store in the database table with the identifier 42 and then use the following call to redirect to
  • If you cannot use a fixed list of redirection targets, filter untrusted input (if you can, using a whitelist, not a blacklist). Make sure to check for partial strings, for example, is a valid URL. Additionally, disallow all protocols except HTTP and HTTPS. Also note, that despite your best efforts it is possible that attackers may find a way around your filters.
Tomasz Andrzej Nidecki
Principal Cybersecurity Writer
Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.