[Proposal] Subresource Integrity Map (sri-map)

Currently there is no way to enforce or check integrity of resources being imported as an ESModule.

There is an existing SRI Standard at W3C which outlines cryptographic hashing functions, an algorithm for response verification, and defines an integrity attribute which is utilized by various elements in HTML. There is an MDN Article on SRI that does a great job of covering some of the higher level benefits as well as provides examples of SRI being used to verify resource in script tags.

There have been a number of discussions at TC39 that have resulted in the committee holding the opinion that Integrity data belongs out of band. There are a number of reasons for this, module cycles and maintainability being the some of the easier to explain.

WICG is already incubating the Import Map proposal, but the explainer outlines that integrity is currently out of scope. There is a possibility that an integrity map and an import map could merge into a single manifest, but it would appear that it should be explored and spec’d on its own merits first.

A straw proposal for syntax below

{
  "https://example.com/example-framework.js": "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
}

The left hand side is the resource, the right hand side the SRI. This would scale to various resource types, not limited to JavaScript. it could integrate into the existing integrity checks already in HTML for any resources in the map. I would imagine that it would likely support all the types of meta data currently support by the integrity attribute

As we see more adoption of modules in JavaScript and individuals consuming resources VIA HTTPS URLs I think having a mechanism for integrity checks with be extremely important, having a standard mechanism for this even more so.

Thoughts?

There is no full integrity modules story right now. This is because lazy loading of modules with dynamic import() does not support integrity. Working towards a concrete solution for the integrity of modules is clearly an important problem so thanks for bringing this up!

SystemJS recently came up across this integrity limitation and without any other proposals being available had to implement a custom solution here. I’d be very interested to see further collaboration in this space.

Other relevant threads include:

• @Jake_Archibald’s suggestion for fetch maps (a more general “stable [module] source text by externalizing hashed names in specifiers”): [Proposal] fetch-maps
• SystemJS’ preload map because a preload map also has to repeat each URL: https://github.com/systemjs/systemjs/issues/1953

Given the potential size of this data and that it likely would have to be shipped in the initial HTML, I think that being cautious with the total size would be important. Collapsing some of these could help but maybe even a less human-readable format could be great.

What is the scope of integrity solutions?

In general, integrity solutions provide answers to the question “does this resource have a property that is easy for a trusted source to arrange it to have but hard for an untrusted source to arrange it to have.”

There are non-hash based ways to answer that question; e.g. signature verification which would require metadata (a public key chain) that is specified once for potentially many modules, not per-URL.

Are module resolution metadata files like import maps in scope for resource integrity checks?

If resource integrity checks apply to all loaded modules but not to import maps, then I could cause

import "a"
import "b"

to load modules out of order. Being able to do anything other than deny service would probably be incredibly situationally dependent, but perhaps:

import "tweak-environment-so-its-safe-to-run-foo"
import "foo"

One argument for putting signature verification explicitly out of scope might be that resources can come from the cache, and it might be tricky for the cache to store enough information to verify a signature for a resource that was initially fetched outside the scope of any integrity metadata.

I just don’t know enough about signed HTTP bodies.

I believe import map scripts themselves do support integrity attributes, which is crucial since the import map does have such a high security position.

That said I just checked the Chrome implementation and apparently it does not, which seems like a problem.

I’ve posted https://github.com/WICG/import-maps/issues/223 to follow up on this.