The draft spec for subresource integrity is straightforward:

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.

Such a solution is a very static one. If a reliable provider wants to change their JavaScript, they have to update the integrity hash and distribute that to all possible users. In essence the object at that address had better never change, ever. If you update your resource, you should give it a new address along with its new hash. (Which makes me think about IPFS, but I digress.) In the (nearly) worst case the clever, but ignorant web developer will dynamically generate the hash from whatever document is being hosted at any given moment.

I'm skeptical of this approach, though – I can send you a document signed with my private key and you, having my public key, can trust the pedigree of that document as much as you trust my public key to be mine. Is there no way to leverage asymmetric key signing to provide a better experience for web developers without undermining security?

Hypothetically, what would be the security impact if (instead of SRI) the following behavior were baked into web user agents:

A primary web server response would include a list of public keys mapped to its subresources. Those resources would be expected to be signed documents. If not, or if the signature doesn't match the expected key, the user agent would take protective measures similar to what the SRI draft spec proposes.

Ultimately I'm trying to understand how providing static hashes of each document is better than key signing in this case.


If a reliable provider wants to change their JavaScript, they have to update the integrity hash and distribute that to all possible users.

Not if the caching policy means that the referer will not be cached for longer than the referee. It's another strong argument for using long expiration times for static content and injecting a variable into the URL. I think (would want to spend some thinking time on this, and testing) that using mod_pagespeed's extend_cache would deliver the desired result without having to wait for browser developers to implement SRI. If smart 404 handling at the origin (i.e. creating a cacheable response rather than a 404) then the heavy lifting could be done on the CDN rather than at the origin.

My immediate thought on reading about SRI was that it should be an extension to CSP indicating what resources are allowed to reference a content item (rather than specifying what content items a resource is allowed to reference). However, IME, most browsers (Firefox is a notable exception) do not have bulletproof referer handling. The only way I can see asymmetric encryption being of any use would be to associate it with the referer mechanism.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.