Every HTTP request has a set of Request Headers which carry pieces of useful information from the client to the server. One such request header is the "Referer" header, which contains address of the previous page from which the current page was requested.
E.g., If you search for "HTML5" on google and click on the first result (link to wikipedia's page), you would be navigated to Wikipedia's HTML5 page and the "Referer" header contains the address of the previous page (i.e., google's search results page). Check the details in the below screenshot of IE9 F12 toolbar.
Over the years, “Referer” header (actual spelling should be “Referrer”, but it was misspelt in specs itself :p) has been used in several useful scenarios.
Fun with referrer:
By using “document.referrer” property in JavaScript, the address stored in referer header can be read. Using this web pages of Web 1.0 era displayed welcome messages, special offers, redirected to personalized landing pages etc.
if (document.referrer != ''){
alert('Hey! Welcome from '+ document.referrer);
}
CSRF protection:
Cross Site Request Forgery (CSRF) is a well known web based attack using which an attacker can make requests on behalf of the user. Leveraging CSRF, an attacker can construct GET/POST requests in a web page and make the victim open the page.
<!-- If this image tag is injected, it generates the below dangerous GET request -->
<img src="http://bank.com/funds/transfer?amount=10000&targetAccount=9876543210"/>
To defend against CSRF, the server has to differentiate between HTTP requests originating from a genuine user’s page vs an attacker’s page. Protecting against CSRF is a well explored area and it has several defenses such as using secret validation tokens, custom headers, Referer header etc. In most cases, the Referer header is used to check if the request is from the expected domain and not from attacker’s domain.
However, security experts have shown that referer headers can be easily stripped (Kotowicz’s demo) in all browsers and hence majority of CSRF defenses depending on referer header will fail.
Privacy Concerns:
In the era of social networks and personalization, data has become the currency of the web. By looking at the referer header, advertisements can learn from which page a user has visited the current page and provide more relevant ads. This means the browsing habits of users are being exposed to the cloud (Watch this Defcon video- How our Browser history is leaking into the cloud).
Till recently, Facebook exposed user’s unique Id in Referer header which caused serious concerns. Sites which are too concerned about privacy prefer to strip referer header and stay safe.
Damn! What web developers frequently use in their requirements is in fact not a recommended practice! Solutions are coming up!
Origin Header:
Researchers at Stanford Web security lab proposed that a new header called Origin Header should be used to uniquely identify requests. It is different from Referer header in that it just contains the origin (scheme://host: port) and not the entire address of the previous page. So this removes the privacy concern and can be used as protection against CSRF.
As far as I’ve seen, Origin header is implemented in Firefox, Chrome as an experimental feature and needs standardization (needs further verification).
Noreferrer: HTML5 introduces a new link type attribute called “noreferrer”. When an anchor tag is decorated with “rel=noreferrer” attribute, the pages which follow the hyperlink will not include referrer information in the header. This would pull down the privacy problem caused by Referer header. As of now, no browser supports this ‘noreferrer’ attribute.
So, the take away is, HTTP Referer header may be a handy option but it bears its own security and privacy problems and hence should be evaluated carefully. Instead, Origin header would be an ideal solution which would cater to the needs of web developers, respecting security and privacy.