'Subresource integrity for images and other media?

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, and video 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?

htmlimagehttpsw3csubresource-integrity


Solution 1:[1]

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:

  1. No guarantees the content hasn't been altered on the wire (which SRI addresses somewhat).
  2. Leakage of cookies (unless protected by Secure attribute).
  3. Leakage of privacy (a snooper knows you've requested that resource).

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).

Solution 2:[2]

I did a little research on this and pulled together what I could in an issue in the spec's github repo.

My impression is that the folks behind the spec got busy and that there wasn't a lot of demand for expanding the spec, but perhaps we'll see more conversation in the issue I just opened.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 mlissner

Related Questions