What is the "Upgrade-Insecure-Requests" HTTP header?

Question

I made a POST request to a HTTP (non-HTTPS) site, inspected the request in Chrome's Developer Tools, and found that it added its own header before sending it to the server:

Upgrade-Insecure-Requests: 1

After doing a search on Upgrade-Insecure-Requests, I can only find information about the server sending this header:

Content-Security-Policy: upgrade-insecure-requests

This seems related, but still very different since in my case, the CLIENT is sending the header in the Request, whereas all the information I've found is concerning the SERVER sending the related header in a Response.

---

So why is Chrome (44.0.2403.130 m) adding Upgrade-Insecure-Requests to my request and what does it do?

---

Update 2016-08-24:

This header has since been added as a W3C Candidate Recommendation and is now officially recognized.

For those who just came across this question and are confused, the excellent answer by Simon East explains it well.

The Upgrade-Insecure-Requests: 1 header used to be HTTPS: 1 in the previous W3C Working Draft and was renamed quietly by Chrome before the change became officially accepted.

(This question was asked during this transition when there were no official documentation on this header and Chrome was the only browser that sent this header.)

Solution 1

Short answer: it's closely related to the Content-Security-Policy: upgrade-insecure-requests response header, indicating that the browser supports it (and in fact prefers it).

It took me 30mins of Googling, but I finally found it buried in the W3 spec.

The confusion comes because the header in the spec was HTTPS: 1, and this is how Chromium implemented it, but after this broke lots of websites that were poorly coded (particularly WordPress and WooCommerce) the Chromium team apologized:

"I apologize for the breakage; I apparently underestimated the impact based on the feedback during dev and beta."
— Mike West, in Chrome Issue 501842

Their fix was to rename it to Upgrade-Insecure-Requests: 1, and the spec has since been updated to match.

Anyway, here is the explanation from the W3 spec (as it appeared at the time)...

The HTTPS HTTP request header field sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the upgrade-insecure-requests directive in order to make that preference as seamless as possible to provide.

...

When a server encounters this preference in an HTTP request’s headers, it SHOULD redirect the user to a potentially secure representation of the resource being requested.

When a server encounters this preference in an HTTPS request’s headers, it SHOULD include a Strict-Transport-Security header in the response if the request’s host is HSTS-safe or conditionally HSTS-safe [RFC6797].

Solution 2

This explains the whole thing:

The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.

The upgrade-insecure-requests directive is evaluated before block-all-mixed-content and if it is set, the latter is effectively a no-op. It is recommended to set one directive or the other, but not both.

The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header, which should still be set with an appropriate max-age to ensure that users are not subject to SSL stripping attacks.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

Comments

[dakab]

Firefox does it too.

[user193130]

Must be new; I do development on Firefox first and this header definitely wasn't sent from Firefox last year.

[Saeed Neamati]

I fail to understand it. I'm a.com and redirect you to b.com, while providing this header to b.com and sending some information. If you're not under a secure channel to b.com, a sniffing-attack can happen already, because I've sent data to b.com alongside my request. Can you guide us to a simple scenario of how it makes connections more secure for users?

[tne]

@SaeedNeamati Under a very strict perspective it doesn't make anything more secure. If you have normal security requirements then you have to make sure you connect via HTTPS first and not rely on this. That being said, I would describe this in the context of the idea of "Trust on First Use", which does help passively.

[DUzun]

I see this more as client's desire than security tool. It's like "DNT" header, server could ignore it, but yet it expresses client's will.

[Simon East]

My answer could actually be improved to properly explain how the client and server negotiate this. Feel free to suggest improvements if you'd like.