Published on

HTTP Referer / Referrer and HTTPS

Authors
  • avatar
    Name
    Mike Barram
    Twitter

The rule for whether the HTTP referrer (incorrectly spelt in the original spec, so forever incorrectly spelt in headers) is sent along with a request has always been a bit odd. If the referring site uses https, the referrer isn’t sent, unless the site linked too also uses https. It isn’t sent because the originating URL may contain sensitive information but the browser happily sends the sensitive URL to any other site if it uses https.

Now, there is a meta tag you can use that tells browsers whether or not to send the referrer. The options are Never, Origin (only the domain name is sent), Default (same as without the tag), Always. If you’re not worried about other sites knowing your site exists and links to their site, <meta name="referrer" content="origin"> seems the best option for sites using htttps.

This has been implemented in Chrome, Safari and recently in Firefox

There’s a better description of this here:
http://smerity.com/articles/2013/where\_did\_all\_the\_http\_referrers\_go.html

It looks like the options are being changed:
http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-meta

They’re now:

  • no-referrer
  • origin
  • no-referrer-when-downgrade
  • origin-when-crossorigin
  • unsafe-url

origin-when-crossorigin sounds like a better option for most intranets, as one page in the intranet can get the full referrer when linked to from another, but external sites (whether using https or not) will just get the domain name. At the moment (27th March 2015), I think Firefox supports these latest values but Chrome doesn’t, so it’s better to use origin.

As well as a page-wide meta tag, you can also set a referrer attribute on the  <a>, <area>, <img> or <iframe> elements:
http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-referrer-attribute