(note: per RFC, we spell the Referer header with one 'r', well aware that in proper English, one would spell the word referrer with double r).

The "Referer" header is frequently considered a privacy concern. Your browser will let a site know which site it visited last. If the site was coded carelessly, your browser may communicate sensitive information (session tokens, usernames/passwords and other input sent as part of the URL).

For example, Referer headers frequently expose internal systems (like webmail systems) or customer service portals.

There are however a few simple tricks you can apply to your website to prevent the Referer header from being sent. For example, RFC 2616 [1] addresses some of this as part of the security section. Section 15.1.2 acknowledges that the Referer header may be problematic. It suggests, but does "not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information". To protect data from HTTPS sessions to leak as part of the Referer sent to an HTTP session, Section 5.1.3 states: "Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol"

So as a first "quick fix" make sure your applications use HTTPS. This is good for many things, not just preventing information to leak via the Referer header. More recently, the WHATWG suggested the addition of a "referrer" meta tag (yes, spelled with double "r") [2]. This meta tag provides four different policies:

• never: send an empty Referer header.
• default: use the default policy, which implies that the Referer header is empty if the original page was encrypted (not just https, but an SSL based protocol).
• origin: only send the "Origin", not the full URL. This will be send from HTTPS to HTTP.  But it just includes the hostname, not the page visited or URL parameters. It is a nice compromise if you link from HTTPS sites to HTTP sites and still would like "credit" for linking to a site.
• always: always send the header, even from HTTPS to HTTP.

For example, a page that contains <meta name="referrer" content="never"> will never send a Referer header. 

In addition, if you would like to block Referer header only for a specific link, you could add the rel=noreferrer attribute [3].

As far as I can tell from a quick test with current versions of all major browser (Firefox, Chrome, Safari), Firefox was the only one not supporting the META tag or the "rel" attribute. Safari and Chrome supported both options. But I would be interested to hear what others find. You can use a link to our browser header page to easily find out what header is being sent: https://isc.sans.edu/tools/browserinfo.html .

[1] http://tools.ietf.org/html/rfc2616
[2] http://wiki.whatwg.org/wiki/Meta_referrer
[3] http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter