A brief history of the referer header

The referer header. Misspelled and misused since its inception. Its typical use is thus: if I click on a link in a webpage that takes me to a different page, the referer header shows the landing page which page I came from. It’s very useful for gathering statistics about reading habits, but also presents a potential security risk, if too much information is passed on.

In the original RFC (2616), the specification lays out that

“Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol”

That is, if the origin of the request was https, the referer header should not be present.

However, RFCs are not mandatory, and data is sometimes leaked. Facebook fell foul of this a little while ago, when it turned out that in some cases the userid of the originating page was being passed in the referer header to advertisers when a user clicked on an advert. Their solution was to implement the meta-referrer tag instead.

The meta-referrer tag can edit the referer header to allow sites to see where their traffic has come from, but without leaking potentially sensitive data.

Google were the first to implement such a scheme, ostensibly to reducy latency from ssl sites, although one would suspect that being able to prove to clients that your site was the source of their traffic would be a more persuasive business argument.

The meta-referrer tag can take one of four values:

Facebook, for example, use this tag so that clicks from their website to external sites indicate that the user came there from facebook, but without any of the information that might be leaked by the full url. In the source code you can see

<meta name="referrer" content="default" id="meta_referrer" />

and even when I’m logged into facebook and on a url such as


when I click on a link and view the headers, the referer header is reduced to


thus preserving my privacy.

Empty when: