Mozilla Security Blog
Categories: Announcements Firefox Privacy Security

Tighter Control Over Your Referrers

mozilla

17 responses

The purpose of the HTTP Referer (sic) header is to help sites figure out where their traffic comes from. However, as the Web got more complex, the amount of information in the Referer header ballooned, leading to bigger privacy problems. Firefox Beta supports a new feature to help sites protect their users’ privacy by changing the Referer header.

HTTP Referer provides a wealth of information about where you came from to the sites you visit, but this context isn’t always necessary (or desired). In addition, it is an unreliable tool for authenticating the origin of an HTTP request unless it’s always present, which it’s not due to privacy concerns (HTTPS sessions should not leak URLs to HTTP). When it is transmitted, there are still privacy concerns (“is that my username in the URL?”) because it’s all (whole URI) or nothing. To get what they want privacy-wise, sites often had to hack around direct loads with redirects and frames to change the referrer to something safer. What’s needed is a better way for referring sites to reduce the amount of data transmitted and thus providing a more uniform referrer that’s less privacy invasive.

This HTTP header has become quite problematic and not very useful, so we’re working to make it better.

Step one was to make gecko more flexible: we laid the groundwork so that it is easier for a user or browser extension to configure when Referer headers are sent and what they contain.

Step two is to help sites protect their users. Firefox 36 Beta now supports a feature called “meta referrer.” (Yes, this time “referrer” is spelled correctly.) Now your HTML documents can include a meta tag that specifies one of many referrer policies for the document to change what Firefox sends in the Referer header, and when it is sent. If your page contains the tag:

<meta name="referrer" content="origin">

all Referer headers in loads from your document will be without a path, query string or fragment, origin only. There are other policies you can specify to suppress referrers entirely, send a stripped-down referrer string cross-origin, and more.

We are proud to add this tool to the suite of features in Firefox that Web developers can use to protect their visitors’ privacy. Try it out! Let us know what you think!

Many thanks to Owen Chu for getting the gecko implementation started.

Sid Stamm
Security and Privacy Engineer

17 comments on “Tighter Control Over Your Referrers”

  1. Ron. wrote on

    Ah, i see you didn’t opt to use the consistently misspelled HTTP header ‘Referer’, and opted to use the correct spelling?

    1. Sid Stamm wrote on

      Correct spelling of “referrer” is what the W3C working group decided to do, yes.
      http://www.w3.org/TR/referrer-policy/#referrer-policy-delivery-meta

  2. Example wrote on

    Will there ever be a referrless future?

    1. Z wrote on

      There is a “none” policy: http://www.w3.org/TR/referrer-policy/#referrer-policy-state-none

  3. David Mentré wrote on

    Is there now a way for the Firefox user to configure this “Referer” header, e.g. to forbid all of its use or a less strict policy?

    1. John Doe wrote on

      Yes, there is. You can open about:config and write “referer” in the search field. Four options should appear: network.http.referer.XOriginPolicy, network.http.referer.spoofSource, network.http.referer.trimmingPolicy and network.http.sendRefererHeader.

      spoofSource is the one I find most useful since it doesn’t break websites and makes them unable to know where I come from. However, the others also give you considerable control over the referer policy. You can find the description of what they do on the Web, with a simple search.

      1. Chris R. wrote on

        So if Mozilla is as pro-privacy as they claim to be, why is there no UI for this in the preferences dialog?

      2. Jesse Ruderman wrote on

        SpoofSource sounds dangerous to me because it can confuse CSRF detection. Did you find sites where it made sites “work” but XOriginPolicy did not?

  4. P wrote on

    Can referrer still be used to protect against CSRF?

    1. Daniel Veditz wrote on

      There are problems using the Referer header to protect against CSRF and it’s not recommended, but if your site does use it then presumably you simply wouldn’t use the feature on your site. Or at least not on pages that post to the forms you’re trying to protect this way. You’d have to treat a missing Referer header as a potential attack (which you should already be doing).

      1. P wrote on

        Thanks for your reply. What are the problems? Referer checking seems much easier to understand and implement robustly than other CSRF protections. (Especially with optional CORS and SPAs with separate APIs also used from non-browser clients.)

  5. Ryan Hitchman wrote on

    Why add the “Unsafe URL” policy when the goal is to improve security? It reads as yet another way to inadvertently risk users’ data– yet another item to add to OWASP.

  6. Richard wrote on

    So this will totally break any deeplink protection.
    Where deeplink protection by referer checking (where an empty referer will allow the resource to be downloaded as well) was always effective enough since the web page author had no way to control the browser’s or users choice of sending a Referer header or not, now the author of a web page that is deeplinking resources is simply able to prevent a Referer header being sent, circumventing the protection mechanism.

    1. Jeppe wrote on

      Not really, this changes nothing for people who want to avoid deep linking. I would presume they currently check if the referrer header start with the base address of their website, and they can just keep doing that unless they specifically turn off the referrer header on their own pages.

      This change doesn’t allow other websites to specify a custom referrer header to send with outgoing links, it only allows one of the options specified in the W3C specifications.

  7. anonymous wrote on

    I’ve been using the RefControl extension ( https://addons.mozilla.org/en-US/firefox/addon/refcontrol/ ) for many years. The feature that I like most is that it can be configured to quash cross-site referrers in a way that doesn’t break sites that pay attention to the header. Selecting the “forge” option means that if I’m on http://foo.example.com/page1.html and I navigate to http://bar.example.com/page2.html, then the ‘bar’ site gets a referrer of just “http://bar.example.com/”, which makes it seem as if I came to page2.html from the front page of their site even though I came from ‘foo’; they know nothing of ‘foo’. And this setting can be applied to just cross-site actions (which the extension refers to as 3rd party), so that if I go from http://bar.example.com/page2.html to http://bar.example.com/page3.html, then the ‘bar’ site gets the full referrer, such that any kind of checking that they perform still works.

    Vary rarely a site will need an exception rule to disable this, but I’ve been using this extension for a number of years and I only have 8 exceptions configured.

  8. Ant wrote on

    I usually disable referers, but a few web sites don’t work when I do that. 🙁

  9. Ant wrote on

    I usually disable referers, but a few web sites don’t work when I do that. 🙁 Even on here to post my comment! Oy!