SRI is a great resource to use if you can. Unfortunately, there exists just enough external libraries which don’t use versioning (i.e. you can’t say scriptname-0.3.1.js instead of scriptname.js which may update), so that if you do use it on those scripts, you can’t guarantee that it will work in perpetuity. The obvious solution is to host that script yourself, but some scripts rely on them being loaded from a particular domain (looking at you utteranc.es!), so it’s not exactly feasible 100% of the time without a lot of effort.
Another thing that is updated since the writing of this article (2015), is that you indeed can have error reporting when SRI hashes fail. If SRI hashes are required under Content Security Policy (CSP) rules, any failure will be logged to the CSP reporting location.
One last point, is that this is a defense for cross-domain CDNs (e.g. you don’t serve your HTML through the same CDN) - so that if you host your site through Cloudflare, they technically can (and benevolently do as a service) perform rewrites to your site, so this doesn’t protect you from them being malicious there.
I wish there was an easy way to protect unversioned files. But I don’t think there is. At this point it’s more likely SRI gets expanded to more html elements rather than seeing a significant change in the integrity mechanisms.
Another thing that is updated since the writing of this article (2015), is that you indeed can have error reporting when SRI hashes fail. If SRI hashes are required under Content Security Policy (CSP) rules, any failure will be logged to the CSP reporting location.
The SRI/CSP integration never really shipped in Firefox and Chrome. It’s always been behind a flag and in the end we removed it from Firefox :(
Hm, that makes total sense. I’m sure there’d be room for something like annotating CSS imports with SRI hashes, and likewise for JS, but I presume no-one would care enough for a feature that necessitates language changes (and for two languages as well!).
Yeah, last I checked, the CSS spec is not defined on top of “fetch” (but SRI depends on it). This means the whole SRI spec can’t easily apply to anything internal to CSS.
SRI is a great resource to use if you can. Unfortunately, there exists just enough external libraries which don’t use versioning (i.e. you can’t say scriptname-0.3.1.js instead of scriptname.js which may update), so that if you do use it on those scripts, you can’t guarantee that it will work in perpetuity. The obvious solution is to host that script yourself, but some scripts rely on them being loaded from a particular domain (looking at you utteranc.es!), so it’s not exactly feasible 100% of the time without a lot of effort.
Another thing that is updated since the writing of this article (2015), is that you indeed can have error reporting when SRI hashes fail. If SRI hashes are required under Content Security Policy (CSP) rules, any failure will be logged to the CSP reporting location.
One last point, is that this is a defense for cross-domain CDNs (e.g. you don’t serve your HTML through the same CDN) - so that if you host your site through Cloudflare, they technically can (and benevolently do as a service) perform rewrites to your site, so this doesn’t protect you from them being malicious there.
I wish there was an easy way to protect unversioned files. But I don’t think there is. At this point it’s more likely SRI gets expanded to more html elements rather than seeing a significant change in the integrity mechanisms.
The SRI/CSP integration never really shipped in Firefox and Chrome. It’s always been behind a flag and in the end we removed it from Firefox :(
Oh! That’s a shame.
According to this it says that Chrome still has it, but it’s out of date.
The problem is and was with interface that don’t allow supplying integrity Metadata.
Disallowing non-SRI styles amd scripts practically also disallows module scripts and
@importin CSS. Not many were willing to bite that bullet.Hm, that makes total sense. I’m sure there’d be room for something like annotating CSS imports with SRI hashes, and likewise for JS, but I presume no-one would care enough for a feature that necessitates language changes (and for two languages as well!).
Yeah, last I checked, the CSS spec is not defined on top of “fetch” (but SRI depends on it). This means the whole SRI spec can’t easily apply to anything internal to CSS.
Module scripts would be doable though.
I didn’t know you were involved in SRI. Great work and write-up!
Is t here any way to protect your site if it’s being served through a CDN? Not just the site’s resources but the pages and everything.
A proxying CDN like Cloudflare? No, they’re a voluntary man-in-the-middle for your website.
If you’re using something like CloudFlare for your pages, then as far as the browser is concerned CloudFlare is your site.