Link Search Menu Expand Document

Open Redirect

  1. Open Redirect
    1. Description
    2. Impact
    3. Scenarios
    4. Prevention
    5. Testing


Open Redirects, otherwise known as Unvalidated Redirects and Forwards, are a class of vulnerability made possible when a web application, comprised of insufficient input-validation controls, is manipulated into redirecting unwitting users of the application to a malicious, attacker-controlled URL.

This type of exploit is popular with criminals involved in phishing and credential theft, unsurprising given the false layer of trust attributed to the fact that the modified link and the original site share the same server name.


There are many overlapping techniques criminals employ to dupe unwitting victims into handing over their hard-earned cash. One of these methods is undoubtedly betting on the misplaced trust many of us place in familiar server names. This write-up exemplifies how even the most arguably well-known URL of all,, can be taken advantage of via its redirection facility.

In addition, Open Redirect vulnerabilities can:

  • Lead to Cross-Site Scripting (XSS) attacks if the redirect uses data: or javascript: protocols;
  • Potentially circumvent Server-Side Request Forgery (SSRF) filters;
  • Nullify allow list effectiveness in some cases to bypass Content Security Policy (CSP);
  • Lead to Carriage Return and Line Free (CRFL) attacks if line breaks are present in the destination parameter.


As outlined above, attackers often use this attack as it ‘hijacks’ the trust users place in a well-known URL.

Here’s a topical example from 2021; if the target domain is, an attacker might craft the following URL:

Attackers send links like the one above in phishing campaigns in the hopes that they will lure a victim into clicking on the link.


The following measures can be applied to either eliminate or drastically reduce the potential for Open Redirect exploitation:

  • If they aren’t necessary, don’t use redirects and forwards!
  • In cases where they are required, do not allow the URL as user input for the destination;
  • When user input is unavoidable, validate the supplied value, its appropriateness for the application, and ensure it is authorized for the user:
    • This can be a fiddly task, so closely adhere to best practices and ensure continued maintenance.
  • If possible, force the user to provide an ID or token that is mapped server-side to a complete target URL;
  • Input sanitization should be implemented by creating an allow list of trusted URLs determined by host or regex.


Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.

Table of contents