MDN wants to learn about developers like you: https://qsurvey.mozilla.com/s3/d6d7ff2e2f9c

我们的志愿者还没有将这篇文章翻译为 中文 (简体)加入我们帮助完成翻译!
您也可以阅读此文章的English (US)版。

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.

Syntax

Content-Security-Policy: upgrade-insecure-requests;

Examples

// header
Content-Security-Policy: upgrade-insecure-requests;

// meta tag
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

With the above header set on a domain example.com that wants to migrate from HTTP to HTTPS, non-navigational insecure resource requests are automatically upgraded (first-party as well as third-party requests).

<img src="http://example.com/image.png">
<img src="http://not-example.com/image.png">

These URLs will be rewritten before the request is made, meaning that no insecure requests will hit the network. Note that, if the requested resource is not actually available via HTTPS, the request will fail without any fallback to HTTP.

<img src="https://example.com/image.png">
<img src="https://not-example.com/image.png">

Navigational upgrades to third-party resources brings a significantly higher potential for breakage, these are not upgraded:

<a href="https://example.com/">Home</a>
<a href="http://not-example.com/">Home</a>

Finding insecure requests

With the help of the Content-Security-Policy-Report-Only header and the report-uri directive, you can set-up an enforced policy and a reported policy like this:

Content-Security-Policy: upgrade-insecure-requests; default-src https: 
Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint

That way, you still upgrade insecure requests on your secure site, but the only monitoring policy is violated and reports insecure resources to your endpoint.

Specifications

Specification Status Comment
Upgrade Insecure Requests
The definition of 'upgrade-insecure-requests' in that specification.
Candidate Recommendation Initial definition.

Browser compatibility

FeatureChromeFirefoxEdgeInternet ExplorerOperaSafari
Basic Support4342.0(No)1(No)30(No)
FeatureAndroidChrome for AndroidEdge mobileFirefox for AndroidIE mobileOpera AndroidiOS Safari
Basic Support?43(No)42.0(No)?(No)

1. Under consideration for future release.

See also

文档标签和贡献者

 此页面的贡献者: fscholz, teoli
 最后编辑者: fscholz,