Hello readers, Today I will address a HTTP header quite common in browsers, but that has little or no practical use. The header name is Referer.
#What is it?
The HTTP Referer is an HTTP header that is sent together with your web requests. It basically serves to identify where the previous request is coming from.
#What is it for?
The first application is to use it to identify where the traffic of a particular website comes from. Several traffic analysis tools make use of this header as part of their identification algorithm. You can use it, for example, to know which blogs are targeting this particular website.
Another more useful application for the referer is security checking. You can check the header and through the information it contains allow, for example, only downloads of the images of the website if the header contains the URL of the website itself, that is, of itself. Or if the request came from a certain search engine. Likewise, it is possible to verify that the header is present when receiving POST requests, thus increasing the security of the forms.
#As a user, why not use it?
The referer can be easily used to track your web activities. Another potential problem is unnecessary bandwidth consumption. If the header is not required, why send it? You will not gain anything by sending a “useless” header. Perhaps in fixed platforms like computers in local network this is irrelevant, but when mobile platforms are used, where the network is usually quite expensive, it is worth saving each possible bit.
#As a developer, why not use it?
Imagine a scenario where there is an “A” blog that makes multiple picture posts. The blog “B” in turn copies the content in its entirety, but instead of hosting the images, it uses the original link from the “A” blog server. Now, in addition to losing traffic, it spends more on network. It is possible to mitigate this problem by checking for the user referer, in order to block the download of images if the referer is a different value from blog “A” or if it is from a search engine. Ready! Problem solved!?
Not so fast! What happens if blog users “A” have the referer blocked? They will not see the pictures. You can advise them to always have the referer on, but what if they are navigating through a proxy (like Squid for example), which has the option of removing the header? In this case there is no way to ensure a secure header check.
#Ok you convinced me, how do I remove the referer?
In Firefox (tested with version 25 to 48) you can go to “about: config” and search for the variable “network.http.sendRefererHeader”. The value 2 indicates always send, while the value 1 indicates that it will send only to a complete request, not sending in image requests for example. The value 0 (zero) indicates off, that is, the header will never be sent. Also look for the variable “network.http.sendSecureXSiteReferrer” and change it to false. So when you navigate from one HTTPS site to another the header will not be sent. By default the option is true, indicating that it will be sent.
In Google Chrome there are no native options to disable this. You can disable the option if you compile the code from the source. There is still the possibility to disable using extensions, but this is not 100% guaranteed.
In Opera you can go to Settings> Preferences> Advanced> Network and uncheck the “Send referrer information” box.
In Internet Explorer you can not find an option that disables sending. Researching this will probably bring you to the following page: [here](http://answers.microsoft.com/en-us/ie/forum/ie9-windows_7/disable-sending-of-http-referrer/98745583-0752 -4987-9d77-ba7915f6dac9) which basically says that: Support for this option does not exist.
#Conclusions
I have been using the browser with this header disabled since early 2014, with very few sites having problems. In programming it is also quite plausible to stop using it since there is no way to guarantee the value of the header.
Note: According to the RFC 2616 sections 14.36, 15.1.2 and 15.1.3, an HTTP header referer is optional.
