#1890 assigned task

submit proposal for restrict-referrer-leakage to the CSP standardizers and implementors

Reported by: zooko Owned by: davidsarah
Priority: normal Milestone: soon
Component: code-frontend-web Version: 1.9.2
Keywords: referer referrer standards capleak research Cc:
Launchpad Bug:

Description (last modified by davidsarah)

In comment:31:ticket:127 and later comments on #127, David-Sarah has written a proposal for a CSP directive to restrict Referer (sic) header leakage. This would be a great fix for issue #127 if it were widely supported. Let's urge browser makers and standards bodies to support it!

Change History (12)

comment:1 follow-up: Changed at 2012-12-05T20:24:15Z by zooko

I recently learned from Brad Hill that it is possible for end-users using Firefox to impose CSP policies:


comment:2 in reply to: ↑ 1 Changed at 2012-12-05T22:47:29Z by davidsarah

  • Description modified (diff)
  • Keywords referrer added
  • Milestone changed from undecided to soon (release n/a)
  • Status changed from new to assigned
  • Summary changed from submit proposal for restrict-referer-leakage to the CSP standardizers and implementors to submit proposal for restrict-referrer-leakage to the CSP standardizers and implementors

Replying to zooko:

I recently learned from Brad Hill that it is possible for end-users using Firefox to impose CSP policies:


There is incidentally already a Firefox pref that allows to never send the Referer header: network.http.sendRefererHeader = 0. Although the ability for end-users to specify CSP policy is interesting for us browser security geeks, it's no easier for security and privacy-conscious Firefox users than setting that pref. The advantage of a CSP policy is that:

a) It just works (on new enough browsers) for sites that need it, without the user having to do anything.

b) It won't be specific to Firefox or any other single browser.

c) The Referer header is only one of several misfeatures that leak the referring site (and potentially the exact URL, when the site is displaying untrusted content). My proposal fixes all of the leaks I know of that are standard parts of HTML5, and states that implementors should apply equivalent policies to any non-standard features (so that other referrer leaks contrary to the policy can be treated as security bugs).

d) It cannot break sites that hypothetically depend on Referer for intra-site links. I think that such sites are almost entirely fictional (and any few that exist deserve to be broken), but browser implementors are invested in such fictions and are therefore are unlikely to make not sending Referer the default, whereas the CSP approach is more politically acceptable.

Part of me rails against writing a spec designed for political acceptability when I know the right thing to do instead (never send Referer, and plug the other cross-origin referrer leaks), but if it helps to stop users getting shafted by this long-standing privacy and security bug, I suppose it's worth it. The draft spec at least says that it only specifies an upper bound on when you can leak referrers, i.e. it's always conformant to leak in fewer cases.

comment:3 Changed at 2012-12-05T23:05:47Z by zooko

This Firefox add-on named "refcontrol" seems pretty good:


I've been using it. There are plenty of sites in my experience that would break with the network.http.sendRefererHeader = 0 tweak. Those ones break when you put refcontrol into the "send nothing" mode, but some of those work when you put it into the "send just the domain part" mode. It also offers "sending this specific string" mode, can be configured to behave differently on different sites, and can optionally display "What I will send in Referer" on the "add-ons display bar" at the bottom of the page.

I configured it many weeks ago to "send just the domain part" by default, and for my children's elementary school district's web site, to send the full normal Referer. Since then I've never had a problem as far as I know, and no Referer's have been sent except to my children's elementary school district. Victory!

comment:4 Changed at 2012-12-06T11:27:05Z by ChosenOne

I am using refcontrol for a few years now. only had problems with pictures on one German site, that nobody uses anymore anyway. I am also using the setting that sends "just the domain part" - but note that it sends the domain of the current(!) host, not of the referring site. This means that when I go from example.com to other.com, Firefox will tell other.com that you have just come from other.com.

Now, that I think of it, this add-on might break naive CSRF-mitigations that check whether the Referer header matches the current domain

comment:5 Changed at 2012-12-06T13:55:41Z by gdt

It strikes me that having to fix this is a clue that putting security-sensitive content in URLs isn't a good idea, or at best a fragile plan. Perhaps capabilities should be treated like passwords within the web world?

comment:6 Changed at 2012-12-06T14:42:12Z by zooko

gdt: one place to put capabilities that other tools would treat with a little more care is in the URL fragment, i.e. the part of the URL that comes after the #. The URL fragment is never sent in the Referer field, for one thing: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127#comment:13

comment:7 Changed at 2012-12-11T22:21:35Z by davidsarah

  • Keywords standards cap-leakage added

comment:8 Changed at 2012-12-11T22:21:53Z by davidsarah

  • Keywords capleak added; cap-leakage removed

comment:9 Changed at 2013-01-04T20:52:25Z by zooko

  • Keywords research added

comment:10 Changed at 2014-09-11T22:36:34Z by warner

  • Component changed from unknown to code-frontend-web

comment:11 Changed at 2014-09-12T20:51:51Z by freddyb

Is this obsoleted with the Referrer Policy proposal? It'sj ust a first public working draft so far, but looking for suggestions in www-tag, for example.


comment:12 Changed at 2021-03-30T18:41:12Z by meejah

  • Milestone changed from soon (release n/a) to soon

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.