Subresource integrity seems to be an awesome stopgap allowing to use third-party controlled HTTP-served resources in a secure way.
However the spec considers HTMLLinkElement
and HTMLScriptElement
interfaces only:
NOTE
A future revision of this specification is likely to include integrity support for all possible subresources, i.e.,
a
,audio
,embed
,iframe
,img
,link
,object
,script
,source
,track
, andvideo
elements.
I understand that content referred to by script
and link
elements is more 'active', yet browsers remove the green padlock for fetching even relatively innocuous images via plain HTTP, while the spec chooses to ignore them? This seems to be a massive lack of foresight to me.
What was the reasoning behind this and when can we expect a 'future revision', if at all?
Using Subresource Integrity You use the Subresource Integrity feature by specifying a base64-encoded cryptographic hash of a resource (file) you're telling the browser to fetch, in the value of the integrity attribute of any <script> or <link> element.
Integrity attribute is to allow the browser to check the file source to ensure that the code is never loaded if the source has been manipulated. Crossorigin attribute is present when a request is loaded using 'CORS' which is now a requirement of SRI checking when not loaded from the 'same-origin'.
The integrity attribute is used to give permission to the Browser to check the fetched script to make ensure the source code is never loaded. It is used to check that whether the third party has been altered the resource or not.
The integrity attribute allows a browser to check the fetched script to ensure that the code is never loaded if the source has been manipulated.
SRI gives you some guarantees that the resource you're asking for has not been altered. For example if you are loading JQuery from a CDN then you want to be sure no one has modified it to include nefarious code (one of the major downsides of loading code from another site - you are implicitly trusting that site's security). SRI gives you that guarantee.
SRI has nothing to say on how it's loaded. You could just as easily download JQuery over http and get an insecure content alert for that despite the fact it's verified by SRI.
Insecure content is bad for lots of reasons, including:
SRI only addresses that first issue. And even then it only stops it being loaded if it's been altered, and doesn't reduce the chance of it being altered (like https does).
If you want to address insecure content issues then you can look at Content Security Policy instead, either to explicitly block those, or by using the upgrade-insecure-requests directive to automatically upgrade them (for browsers that support this).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With