When a site moves to HTTPS, one of the most common annoyances is the browser warning about mixed content: the page itself is loaded securely, but some images, iframes, or other resources are still requested over plain HTTP.
That is exactly what the browser is trying to tell us with messages like this:
Mixed Content: The page at "//www.taobao.com/" was loaded over HTTPS, but requested an insecure image "http://g.alicdn.com/s.gif". This content should also be served over HTTPS.
After an HTTPS migration, it is easy to see warnings like the one below on many pages:
In practice, this is not surprising. Many operations teams do not think in technical terms about HTTPS, and when they fill in content or configure resources, HTTP links inevitably slip in. With a large system, omissions and leaks are hard to avoid completely.
Using upgrade-insecure-requests in CSP
Fortunately, the W3C working group took the pain of HTTPS migration into account. In April 2015, it published a draft called Upgrade Insecure Requests, whose job is to let the browser upgrade requests automatically.
Add the following response header on the server:
<table> <thead> <tr> <th>header("Content-Security-Policy: upgrade-insecure-requests");</th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
</tr>
</tbody>
</table>
If a page is served over HTTPS and contains a lot of HTTP resources such as images or iframes, the browser will detect this header and automatically replace those HTTP requests with HTTPS ones during loading. Google provides a demo of this behavior:
One odd thing is that the resource appears to be requested twice, which may just be a browser implementation bug:
If it is inconvenient to change the server or Nginx configuration, you can also place a meta tag in the page:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"></th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
</tr>
</tbody>
</table>
At the moment, support is still limited; Chrome 43.0 is the browser that supports it here. Even so, CSP is likely to become an important part of front-end security, and upgrade-insecure-requests should move into RFC form soon.
From the examples provided by the W3C working group, it is also clear that this setting does not touch external-domain a links, so it can be used without worrying about breaking normal outbound links.