Why did browser authors not make 127.0.0.1/localhost-hosted webpages skip the referrer?

Question

For a long time, I was so convinced that 127.0.0.1/localhost-hosted webpages, that is, with URLs such as:

http://127.0.0.1/MySecretControlPanel/sensitive.php?stuff=goes&here=dude

... did not send the "HTTP referrer" header when you click hyperlinks on them.

But they do! That is, unless you go out of your way and figure this out and proactively add a special header:

<meta name="referrer" content="no-referrer">

This means that, for the longest time, every damn site I visited by following a link in my control panel was seeing my private, sensitive URLs!

I clicked a ton of links. I have shortcuts in many cases which let me easily check things. All of those sites could see my URLs. Even though they were localhost-hosted.

Again, I was so sure that browser authors would have the basic sanity to skip the header for such websites. After all, they explicitly skip 127.0.0.1/localhost for proxies by default, so in my mind, this was a given. But it wasn't a given. It was not done at all.

Now, a bunch of sites in the world could in theory figure out exactly what I have looked at on their site (because the name of my application and thus the URL after the / is very unique), and they also have tons of sensitive "search query" kind of data which I inputted thinking that it would be private and secure, when in reality, the stupid damn browser (Firefox/Pale Moon) was just leaking that data to the world.

I just wonder why they made this decision. The entire concept of "referrers" is evil to begin with, at least if it includes more than the hostname. At least if they only saw "127.0.0.1", that would not be as bad.

And it doesn't help to tell me that I "should have checked". I know that I should've. Just like I will know that I "should've" done this and that thing after it's too late, but the point is that I never thought about testing it because it seemed like something that didn't even need to be tested.

Answer 1

Don't blame the browser authors, as they just follow the HTTP protocol. The specification of the Referer header in RFC 7231, 5.5.2 does acknowledge the privacy concerns, but it only forbids sending the URL of a secure HTTPS page over unsecured HTTP channel:

The Referer field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. 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. See Section 9.4 for additional security considerations.

You should not put sensitive data on the URL due to information exposure through query strings in url. The Referer header is not the only way to leak this information:

• Referer Header
• Web Logs
• Shared Systems
• Browser History
• Browser Cache
• Shoulder Surfing