Наши волонтёры ещё не перевели данную статью на Русский. Присоединяйтесь к нам и помогите сделать эту работу!
Вы можете также прочитать эту статью на English (US).

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match.

Note: For subresource-integrity verification of a resource served from an origin other than the document in which it’s embedded, browsers additionally check the resource using Cross-Origin Resource Sharing (CORS), to ensure the origin serving the resource allows it to be shared with the requesting origin.

How Subresource Integrity helps

Using Content Delivery Networks (CDNs) to host files such as scripts and stylesheets that are shared among multiple sites can improve site performance and conserve bandwidth. However, using CDNs also comes with a risk, in that if an attacker gains control of a CDN, the attacker can inject arbitrary malicious content into files on the CDN (or replace the files completely) and thus can also potentially attack all sites that fetch files from that CDN.

Subresource Integrity enables you to mitigate some risks of attacks such as this, by ensuring that the files your web application or web document fetches (from a CDN or anywhere) have been delivered without a third-party having injected any additional content into those files — and without any other changes of any kind at all having been made to those files.

Using Subresource Integrity

You use the Subresource Integrity feature by specifying a base64-encoded cryptographic hash of a resource (file) you’re telling the browser to fetch, in the value of the integrity attribute of any <script> or <link> element.

An integrity value begins with at least one string, with each string including a prefix indicating a particular hash algorithm (currently the allowed prefixes are sha256, sha384, and sha512), followed by a dash, and ending with the actual base64-encoded hash.

Note: An integrity value may contain multiple hashes separated by whitespace. A resource will be loaded if it matches one of those hashes.

Example integrity string with base64-encoded sha384 hash:

sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC

So oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC is the "hash" part, and the prefix sha384 indicates that it's a sha384 hash.

Note: An integrity value's "hash" part is, strictly speaking, a cryptographic digest formed by applying a particular hash function to some input (for example, a script or stylesheet file). But it’s common to use the shorthand "hash" to mean cryptographic digest, so that's what's used in this article.

Tools for generating SRI hashes

You can generate SRI hashes from the command-line with openssl using a command invocation such as this:

cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

or with shasum using a command invocation such as this:

shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64

Notes:

  • The pipe-through-xxd step takes the hexadecimal output from shasum and converts it to binary.
  • The pipe-through-awk step is necessary because shasum will pass the hashed filename in its output to xxd. That can have disastrous consequences if the filename happens to have valid hex characters in it — because xxd will also decode that and pass it to base64.

Additionally, the SRI Hash Generator at https://srihash.org/ is an online tool you can use to generate SRI hashes.

Content Security Policy and Subresource Integrity

You can use Content Security Policy to configure your server to mandate that specific types of files require the use of Subresource Integrity. Do this using the require-sri-for directive in your CSP header. For example:

Content-Security-Policy: require-sri-for script;

This requires that any attempts to load JavaScript will only succeed if the Subresource Integrity information is in place and the integrity check succeeds.

You can also specify that SRI should be used when loading stylesheets:

Content-Security-Policy: require-sri-for style;

You can also specify both script and style to mandate SRI for both kinds of file.

Cross-Origin Resource Sharing and Subresource Integrity

For subresource-integrity verification of a resource served from an origin other than the document in which it's embedded, browsers additionally check the resource using Cross-Origin Resource Sharing (CORS), to ensure the origin serving the resource allows it to be shared with the requesting origin. Therefore, the resource must be served with an Access-Control-Allow-Origin header that allows the resource to be shared with the requesting origin; for example:

Access-Control-Allow-Origin: *

Examples

In the following examples, assume that oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC is already known to be the expected SHA-384 hash (digest) of a particular script example-framework.js, and there’s a copy of the script hosted at https://example.com/example-framework.js.

Subresource Integrity with the <script> element

You can use the following <script> element to tell a browser that before executing the https://example.com/example-framework.js script, the browser must first compare the script to the expected hash, and verify that there's a match.

<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

Note: For more details on the purpose of the crossorigin attribute, see CORS settings attributes.

How browsers handle Subresource Integrity

Browsers handle SRI by doing the following:

  1. When a browser encounters a <script> or <link> element with an integrity attribute, before executing the script or before applying any stylesheet specified by the <link> element, the browser must first compare the script or stylesheet to the expected hash given in the integrity value.

    Note: For subresource-integrity verification of a resource served from an origin other than the document in which it’s embedded, browsers additionally check the resource using Cross-Origin Resource Sharing (CORS), to ensure the origin serving the resource allows it to be shared with the requesting origin.

  2. If the script or stylesheet doesn’t match its associated integrity value, the browser must refuse to execute the script or apply the stylesheet, and must instead return a network error indicating that fetching of that script or stylesheet failed.

Specifications

Specification Status Comment
Subresource Integrity Recommendation  
Fetch Living Standard  

Browser compatibility

<script integrity>

Update compatibility data on GitHub
DesktopMobile
ChromeEdgeFirefoxInternet ExplorerOperaSafariAndroid webviewChrome for AndroidEdge MobileFirefox for AndroidOpera for AndroidiOS SafariSamsung Internet
Basic supportChrome Full support 45Edge Partial support 17Firefox Full support 43IE No support NoOpera Full support YesSafari Full support YesWebView Android Full support 45Chrome Android Full support 45Edge Mobile No support NoFirefox Android Full support 43Opera Android ? Safari iOS No support NoSamsung Internet Android Full support 5.0

Legend

Full support  
Full support
Partial support  
Partial support
No support  
No support
Compatibility unknown  
Compatibility unknown

CSP: require-sri-for

Update compatibility data on GitHub
DesktopMobile
ChromeEdgeFirefoxInternet ExplorerOperaSafariAndroid webviewChrome for AndroidEdge MobileFirefox for AndroidOpera for AndroidiOS SafariSamsung Internet
Basic support
Experimental
Chrome Full support 54Edge No support NoFirefox Full support 49
Disabled
Full support 49
Disabled
Disabled From version 49: this feature is behind the security.csp.experimentalEnabled preference (needs to be set to true). To change preferences in Firefox, visit about:config.
IE No support NoOpera Full support 41Safari No support NoWebView Android Full support 54Chrome Android Full support 54Edge Mobile No support NoFirefox Android Full support 49
Disabled
Full support 49
Disabled
Disabled From version 49: this feature is behind the security.csp.experimentalEnabled preference (needs to be set to true). To change preferences in Firefox, visit about:config.
Opera Android Full support 41Safari iOS No support NoSamsung Internet Android Full support 6.0

Legend

Full support  
Full support
No support  
No support
Experimental. Expect behavior to change in the future.
Experimental. Expect behavior to change in the future.
User must explicitly enable this feature.
User must explicitly enable this feature.

See also

Метки документа и участники

Обновлялась последний раз: sideshowbarker,