photobank.kiev.ua - Fotolia
Firefox 26 beta has amended referer headers to protect user privacy. What is the issue with existing referer headers,...
and how does this change affect user privacy? Should our developers consider amending ours?
HTTP referer is an optional HTTP header field sent by a Web browser to a Web server as part of an HTTP request for a resource such as a webpage; it contains the address of the webpage that linked to the resource being requested.
So, for example, if a user clicks on a hyperlink on the SearchSecurity home page -- http://searchsecurity. techtarget.com/ -- that takes them to https://www.computerweekly.com/, the content of the HTTP referer field will be http://searchsecurity. techtarget.com/. Logging this information enables webmasters to analyze where visitors to their site are coming from as they can see where requests originated by checking the referer information.
However the URL of a webpage can comprise more than just the address of the page itself. It can also include query strings, usernames and other data that reveals personal or sensitive information. For example, the Healthcare.gov website was found to be sending personal data such as zip code, income level, smoking status and pregnancy status in its HTTP referer headers to Google's data analytics service, Twitter, Facebook and several online advertising providers.
Because referer information can cause privacy issues, various methods have appeared that block or change the content of the referer field. Some proxy and firewall software will filter out referer information or only provide the top-level address of the website. Various browser plug-ins and security software can manipulate the HTTP request to send blank or inaccurate data in the referer field while Firefox provides the option to turn off the referer field in the request header. Mozilla has also begun trialing a new meta tag -- "meta referrer" -- in Firefox 36 beta to help sites protect their users' privacy by changing the referer header. It allows HTML documents to specify one or more referrer policies that change the way Firefox sends referer headers, such as stripping out path, query strings and other data fragments -- or suppressing it entirely.
However, suppressing or manipulating the HTTP referer header can cause problems; some Web servers block parts of their website to browsers that do not send the expected referer information in an attempt to prevent deep linking or unauthorized use of images. Even though it is an unreliable tool for authenticating the origin of an HTTP request, some sites use referer information to secure their content, only allowing access to users who arrive from a set of approved pages.
There is certainly a need for a better way of referring sites to control the amount of data transmitted in the referer field and provide more uniform referrer information that's less privacy invasive. HTML5 supports the rel attribute value "noreferrer", which specifies the browser should not send an HTTP referer header if the user follows the hyperlink:
<a href="https://searchsecurity.techtarget.com/" rel=" noreferrer"> SearchSecurity</a>
The W3C draft Referrer Policy also introduces a new referrer directive that allows a webmaster to set various referer policies for browsers to follow. While all these initiatives give webmasters easier control over the content of the referer field when users follow hyperlinks on their webpages, unless there is across-the-board support by browsers and Web developers incorporate them into their site's design, their effectiveness in protecting users' privacy is reduced. For example, users have no control over whether a Do Not Track header request is honored or not.
Enterprises should certainly check how their users' browsers are configured in terms of when HTTP referer headers are sent and what they contain to ensure sensitive data isn't being leaked. Website administrators should also review what referer information is being sent when links on their pages are clicked. If sensitive information of any kind is included, then the construction of hyperlinks should be reviewed in order to protect visitors' privacy.
Ask the Expert:
SearchSecurity expert Michael Cobb is ready to answer your application security questions -- submit them now. (All questions are anonymous.)
Learn more about the balance between privacy and security
Dig Deeper on Web browser security
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading