Referer is passed from HTTPS to HTTP in some cases... How?

Question

In theory browsers do not pass on referer information from HTTPS to HTTP sites. And in my experience this has always been true. But I just found an exception, and I want to understand why it works so I can use it as well.

Search for "what is my referer" on https://www.google.ca/
eg: https://www.google.ca/search?q=what+is+my+referer

There are a few sites that will show referer. They all seem to "work" when they shouldn't. For example, click the www.whatismyreferer.com one. I get:

 Your referer:
 https://www.google.ca/

Note that sometimes, rarely, I get "no referer" as the result. Go back and click the link again and it'll "work" the next time.

This should not happen. www.whatismyreferer.com is a non-HTTPS site. The referer header should not be being passed, but it is.

What's going on here, and how can I do the same from my HTTPS site to the HTTP sites I'm linking to?

Solution 1

Looks like it's due to a new <meta> header that Google is using:

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

Specification: https://w3c.github.io/webappsec-referrer-policy/

It's currently only fully supported by a few browsers, so it's not a complete solution, but certainly a start!

Solution 2

This is the standard behavior.

https://www.rfc-editor.org/rfc/rfc2616#section-15.1.3 says

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

so if your client is doing that, it is violating the standard.

then again, google IS the standard, and they can do whatever they want :-)

Solution 3

This appears to be something that the javascript on the google page is doing. I don't see it in firefox with noscript enabled and stop seeing it in Chrome on Windows if I disable javascript. I don't know what specifically as I haven't dug any deeper than that.

Comments

[ravisorg]

I should note that I'm using Chrome on Windows, if that makes any difference (eg: if other people are seeing different results on different browsers / OSs)

[Flimm]

This behaviour is not true any more.

[Pacerier]

@ravisorg, Shouldn't this be posted on S/O instead?

[Silas S. Brown]

Google now returns an HTTPS link, so the test is no longer valid :-(

[ravisorg]

Are you guessing, or are you basing that on fact? Because I don't see that happening on my end. Clicking the link sends you to an HTTPS redirect on google.ca and then on to the end domain. I never hit a non-https URL until I reach (eg) www.whatismyreferer.com. Also note the referer specifically states httpS://www.google.ca, not http.

[ravisorg]

Nope, it's not javascript related (I thought of that and checked it out before asking). Looks like it's a new <meta> tag that Chrome is following.

[user2299634]

Here is the dump of the http headers : pastebin.com/Y1HJyJ87 I just stripped resources download (like google suggest & other ajax stuff) and cookies related datas. But I have to admit that when I tried multiple times, google behaved differently... Sometimes using only https, therefore not allowing the website to show me my referer. Just try by yourself

[Etan Reisner]

Disabling javascript reliably prevents the referrer from working here. I don't know. Maybe more than one thing is involved here.

[ravisorg]

That's very interesting - I'm going to experiment more with that. Thanks for the feedback!

[Pacerier]

"Should" means optional right?

[johnshen64]

yeah, i would think so, optional.

[Pacerier]

Since it's optional, Why do you say that it is violating the standard?

[DocRoot]

This is the same as the already accepted answer?!

[Peter]

By now 2616 is obsolete. 7231 Section 5.5.2 says "A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol." It does not specify what agents are supposed to do for secured HTTP requests though.