We are recently seeing a number of external sites trying to leverage the core of EE to use our site to force referrals that look like they are coming from our domain. My assumption is they are trying this to juice up their referrals for search engine rankings. What they do is hit our site with URLs like:


This then redirects from our site to that external site. In doing some digging this is something built into the EE Core:


There is a check that stops the links from auto-redirecting with an interstitial page, but that is only a small bit of protection.

if ($force_redirect == TRUE OR ( ! isset($_SERVER['HTTP_REFERER']) OR !     stristr($_SERVER['HTTP_REFERER'], $host)))
    // Possibly not from our site, so we give the user the option
    // Of clicking the link or not

$str = "<html>\n<head>\n<meta http-equiv='Content-Type' content='text/html; charset=utf-8'/>\n<title>Redirect</title>\n</head>\n<body>".
        "<p>To proceed to the URL you have requested, click the link below:</p>".
        "<p><a href='".$_GET['URL']."'>".$_GET['URL']."</a></p>\n</body>\n</html>";

Is there a way to better prevent this kind of "referrer-jacking"?

  • Looks like this post has the suggestion of tweaking the HTACCESS to switch sending the '?URL=' type links to a 410 "GONE" page rather than a the 404. This seems more extreme than what I was looking for, but if that's what needs to be done… Commented Dec 27, 2013 at 14:57

4 Answers 4


I know it'd be hacking core, but wouldn't throwing a rel="nofollow" attribute on the anchor negate the effectiveness of this?


According to the bug reported by Mark Drzycimski, for those who don't have an Ellislab account, the solution is listed as follows:

In /system/expressionengine/libraries/Redirect.php on line 50, change:

"<p><a href='".$_GET['URL']."'>".$_GET['URL']."</a></p>\n</body>\n</html>";


"<p><a href='".$_GET['URL']."' rel='nofollow'>".$_GET['URL']."</a></p>\n</body>\n</html>";

  • You had the right idea and who knows when they updated that bug thread :)
    – Natetronn
    Commented Dec 30, 2013 at 20:08
  • So hacking the core is the official solution? Do we know if Ellis plans to roll this fix into a future release? I really hate hacking the core as it then requires me to remember to go back in and re-apply the fix after we update. Commented Jan 2, 2014 at 18:12
  • The bug on the ellislab.com tracker (support.ellislab.com/bugs/detail/20029) has been accepted and received official commentary, so I assume that something will be done… eventually. :-) Commented Jan 2, 2014 at 20:29

I can see two alternatives to this:

  1. Disable external linking. This would break various things like addon doc links in the control panel.
  2. Die rather than provide the external link when referrer != host. This is a much safer solution, but relies on your server providing valid referrer strings. Refreshing a redirected link that times out may also fail.

For solution #1 below line 39 which starts with:

$host = 


if ( ! isset($_SERVER['HTTP_REFERER']) OR ! stristr($_SERVER['HTTP_REFERER'], $host))

And for solution #2 below line 43 which starts

if ($force_redirect



In either case you could redirect to your homepage instead of just using die.

Edit: And as mentioned elsewhere the same idea can be accomplished via htaccess. The only real solution lies in an EE internal whitelist that automatically tracks valid external links. For example every time an addon is added any external URLs are added to the whitelist.

<p><a href='".$_GET['URL']."' rel='nofollow'>".$_GET['URL']."</a>

Leeds to XSS vulnerability. Change to something like :

<a href='".htmlspecialchars($_GET['URL'])."' rel='nofollow'>".htmlspecialchars($_GET['URL'])."</a>

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.