Subresource integrity for images and other media?

Question

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?

Pantheas

This problem can be solved by using a javascript function, served from the same server that the trusted checksum is served from, to verify the integrity of the download from the untrusted server. See meixler-tech.com/aivwd for more info. – Mayapple

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

Moreira

I am aware of the shortcomings of SRI. There is not much that can be done when the resources are not under your direct control. The question is why the differential treatment (element-wise) in the spec and is there any movement towards expanding/improving it. – Pantheas

Probably better addressed at the spec authors. As you say the more critical ones have been addressed first and they themselves say in the spec they've considered this and a future revision is likely to include that. So not sure what more you are looking for. My answer was more to address your comment regarding the green padlock - SRI does not attempt to solve that. – Moreira

What I am looking for is an actual answer to my last question. Presumably from the 'spec authors' or someone else 'in the know' of any discussion related to this when the spec was conceived – Pantheas

Well there are plenty of contact details on the spec so suggest that would be the better place to ask this. Unless someone who worked on it happens to see your question here, the best the rest of us can do is guess. I would suggest raising an issue in GitHub page linked there to ask this question there. Would be good to add an answer here once you get one there. – Moreira

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

Babyblueeyes