This flaw is ranked #10 on the OWASP Top 10. It is the last one of the top 10, so it is not the most “important” but is doesn’t mean we can ignore it, quite the contrary.
This vulnerability empowers phishing attacks. It helps attackers gaining the trust of their victims.
In some cases, it also helps attackers accessing resources their should not be able to access.

How does this flaw work?

Change direction illustration

Many websites use redirection mechanisms, for various use cases. One typical use case is to redirect users to the login page before redirecting them back to the page they were trying to access (once logged in). Another scenario is a redirection mechanism aiming at counting and analyzing clicks on external links.

Example of a redirection URL:

Attack scenario:

  1. The victim receives an email containing a link like the one above.
  2. The victim clicks on the link, which seems to be quite harmless (the website is well-known to the victim).
  3. Once the user is logged in, will redirect them to the website
  4. This time the victim is on a dangerous website. The attacker might have prepared a landing page looking almost like the one on, asking the victim to type his password again for any reason.

The attacker has successfully collected his victim’s credentials.

The website ( is redirecting users to the page specified by the “goto” parameter.
If this parameter is not properly verified or controlled, then it is vulnerable to redirection attacks.

Here is a short video illustrating the attack:


Technical solutions to avoid these redirections flaws

Many solutions exist to protect yourself against that vulnerability, like:

  • simply removing the redirection mechanisms? If you can do without it, then just get rid of this kind of behavior. The simpler, the better.
  • verifying the “referrer” during the redirection process, to make sure external websites do not send potential victims to your redirection page. It should come from your website.
  • deactivating redirections to domains you don’t manage.
  • using a destinations whitelist
  • signing redirections with a hash, in order to validate the authenticity of the URL the user will be redirected to.

Sometimes, redirection mechanisms must remain quite “open”, making it harder to secure them. in this case, monitoring logs and websites statistics is necessary, in order to make sure no redirection has been exploited in a malicious way.

Other articles in this series: