Add a build-tool option to generate subresource integrity metadata

[pimterry]

trafficstars

Library Affected: workbox-webpack-plugin

Browser & Platform: Everywhere

Issue or Feature Request Description: SRI works really well with precaching. It's easy to implement (see https://github.com/google/WebFundamentals/pull/9165) and I think with a generated manifest it's always preferable. I.e. I don't see any plausible use cases where you want to generate a manifest of content to precache, but you don't know for sure what content you're expecting.

Given that it's preferable, it has a huge upside, both in security but also reliability: I've seen real production situations where CDN response bodies were truncated, and the default precaching settings broke my app (persistently!) by caching syntactically invalid scripts.

Is there a clear argument for why including integrity checks with precache manifests isn't the default?

[jeffposnick]

Hello @pimterry!

workbox-precaching allows you to precache opaque responses by default, i.e. there is no requirement that cross-origin URLs in your precache list are served with CORS.

Using SRI with cross-origin URLs only works if the remote server supports CORS.

If generating SRI info is straightforward via a node module, as you illustrate in your example, then I'd be in favor of making it easier for folks to do that via, say, an opt-in configuration option, with documentation that warns folks not to turn it on if there are cross-origin, non-CORS URLs in their precache list.

Making this opt-in also has the advantage of not being a breaking change.

[pimterry]

Interesting! That makes sense, that's a solid case where precaching in general can't use this.

That said, for manifest generation I'm surprised that that's supported - I'm only suggesting enabling this in the manifest generation step, rather than for all precaching. Is it expected that you'd generate a manifest for a site and generate a service worker in the same build from that manifest, but then serve some of the build content from a different origin? Aren't all paths in manifests relative to the origin of the service worker?

An easy option to enable this would be nice to have anyway imo. Doesn't affect me much at this stage since I've set it up myself now anyway, but I would've saved a bunch of time debugging and then digging through webpack docs yesterday if this more easily available :smile:

[jeffposnick]

Over the years, I've found that there's a non-trivial number of folks who deploy all their locally-built subresources to a CDN, and then use the modifyURLPrefix option to prepend the CDN's URL in the manifest. So that's a use case we need to continue supporting.

I'll leave this issue open to track adding in an opt-in configuration option for SRI.