Subresource Integrity Becomes a W3C Recommendation

The fundamental line of trust on the Web is between the end-user and the Web application: individuals who visit a website rely on HTTPS to trust that they are getting the page or application put there by the site owner. Features of Web Application Security are designed to support that trust, protecting against cross-site scripting and content-injection attacks or unwanted snooping on Web traffic. If a Web application includes resources from third parties, however, it may effectively delegate its trust to all of those included resources, any of which could maliciously or carelessly compromise the overall security of the Web application and data shared with it.

Subresource Integrity (SRI), which just reached W3C Recommendation status, offers a way to include resources without that open-ended delegation. It lets browsers, as user-agents, cryptographically verify that the integrity of included subresources such as scripts and styles, matches as-delivered what was expected by the requesting application.

As explained in the specification:

Sites and applications on the web are rarely composed of resources from only a single origin. For example, authors pull scripts and styles from a wide variety of services and content delivery networks, and must trust that the delivered representation is, in fact, what they expected to load. If an attacker can trick a user into downloading content from a hostile server (via DNS poisoning, or other such means), the author has no recourse. Likewise, an attacker who can replace the file on the Content Delivery Network (CDN) server has the ability to inject arbitrary content.
Delivering resources over a secure channel mitigates some of this risk: with TLS, HSTS, and pinned public keys, a user agent can be fairly certain that it is indeed speaking with the server it believes it’s talking to. These mechanisms, however, authenticate only the server, not the content. An attacker (or administrator) with access to the server can manipulate content with impunity. Ideally, authors would not only be able to pin the keys of a server, but also pin the content, ensuring that an exact representation of a resource, and only that representation, loads and executes.
This document specifies such a validation scheme, extending two HTML elements with an integrity attribute that contains a cryptographic hash of the representation of the resource the author expects to load. For instance, an author may wish to load some framework from a shared server rather than hosting it on their own origin. Specifying that the expected SHA-384 hash of https://example.com/example-framework.js is Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7 means that the user agent can verify that the data it loads from that URL matches that expected hash before executing the JavaScript it contains. This integrity verification significantly reduces the risk that an attacker can substitute malicious content.
This example can be communicated to a user agent by adding the hash to a script element, like so:

<script src="https://example.com/example-framework.js"
        integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
        crossorigin="anonymous"></script>

With SRI, WebApps can improve their network performance and security together. Read the Implementation Report for more examples and sites already using the feature.

Thanks to editors Devdatta Akhawe, Dropbox, Inc.; Frederik Braun, Mozilla; François Marier, Mozilla; and Joel Weinberger, Google, Inc. and participants in the Web Application Security Working Group for successful completion of this Recommendation.