As of today, I believe every major browser will by default reveal to a third-party site which site I came from, and more specifically, the exact URL I came from.

What are the privacy implications of the "Referer" being shared, and is this a violation of cross-domain policy?

I'm asking this in the context of a recent news story whereby URLs supposedly known only to the website provider and its user were leaked to third parties. To forestall any objections that URLs aren't private enough, let's just imagine a variant of HTTPS which doesn't encrypt the URLs "because they aren't supposed to be private".

  • 1
    For the record, this is no longer the question I asked; it's been edited and became a different question.
    – RomanSt
    Commented May 7, 2014 at 6:39
  • You can rollback if you're not happy. ;-) Commented May 7, 2014 at 8:59
  • 1
    Agree with the rollback suggestion. We know what the privacy risks are, OP seems to be looking for justification from historical context.
    – bobince
    Commented May 7, 2014 at 20:03
  • asking about "acceptability" and "supposed to be" is subjective and will lead to opionated answers, see the Help @ security.stackexchange.com/help/dont-ask; you can roll back if you want, but the original question is opinionated: No its not supposed to be private, that is not part of the protocol design
    – Eric G
    Commented May 8, 2014 at 2:15

4 Answers 4


Why is this considered acceptable?

It's not considered acceptable by everyone. It's a poor compromise between privacy and utility that is seen by many as a historical mistake.

In other words, why isn't the Referer header subject to a cross-domain policy?

Referer predates Netscape's introduction of JavaScript and the Same Origin Policy that came with it. The web was a very different place back then, predominantly public static documents and little interaction. In this environment there was little prospect of a URL containing anything private, and it seemed useful to let web authors know exactly which documents were linking to theirs, in the spirit of open citation.

Also significantly back then there were no cookies. So if your browser told site A that you had come from site B, there was very little site A could do with that information. It could not spot a previously-planted cookie to tie up that referer information with anything else it knew about what you had done in the past, and it certainly couldn't let third-party cookies spread that information to generate a long-term cross-site tracking profile like the Googles of today do.

It was only when the feature set of the modern 'webapp' came together, including scripting, cookies and frames, that it became obvious that Referer was the wrong thing to do. If it were designed today we would at most have something like the modern Origin header from CORS, which has the slightly-more-privacy-tilted compromise of a site name but no path/query.

However enough web sites (unwisely) rely on Referer that a single browser manufacturer can't easily disable the feature without negatively affecting compatibility for their users. This makes it very difficult to ever fix.


Because when computer scientists came up with HTTP protocol back in the early 1990s, they thought it was a worthwhile to include a referer field (note they even misspelled the English word referrer), so you can track who is linking to your webpages -- maybe you want to reciprocate and link back.

It is only sent if you follow a link somewhere; e.g., if you copy or type a new URL in the address bar, the HTTP Referer field will not be sent. You should note that many [all?] browsers will still send the referer field even when you are private-browsing, because otherwise they may break websites that check against the referer field.

The same-origin policy that restricts cross domain requests only refers to restricting accessing the DOM, specifically to protect cookies and javascript from being able to control someone else's page unless specifically allowed.


Cross Domain policies deal with executing code not under the current domain/subdomains control - e.g., running someone elses code. This is a security issues.

Sending your "referer" to another site is a privacy concern. You can use a proxy or a browser addon to remove referral information. So yes, in general this should be privacy concern if using a vanilla browser with no proxy or plugins.

The referral information has some useful purposes, e.g., if you know what the URL from the search engine is, you could highlight the search terms in the document for the user. Also, it forms a weak measure of restricting access, but is certainly easy to spoof. It is a weak form of CSRF protection.

  • So it's a privacy concern that's trivial to address, but isn't being addressed. Why is that? Do the users of the browsers want it? Or is this feature mainly there for the benefit of those who run websites?
    – RomanSt
    Commented May 7, 2014 at 6:37
  • @romkyns Because it would probably break a lot of things for one. Some sites rely on this header being present and valid for the local domain. Commented May 7, 2014 at 8:58
  • @romkyns The protocol is functioning the way its designed. HTTP is old, at the time the researchers who primarily used it to communicate and share didn't have the same concerns.
    – Eric G
    Commented May 8, 2014 at 2:18

Referers are also used to prevent "hotlinking" of resources such as images. If your request's referer does not match the domain that the resource is hosted on then you are denied access.

  • 1
    A privacy fix would not have to break this: the Referer header could still be supplied if the destination is on the same domain.
    – RomanSt
    Commented May 8, 2014 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .