More detail on this: in a browser's current usage model, this is vulnerable to a 'cache origin confusion attack'. See this thread [1]. It's a bit hard to follow, so perhaps see these posts [2][3], which state the problem succinctly. Let me adapt the text from [3]:
The problem is that www.victim.example/evil.js doesn't exist, and never did, but your browser won't know that if it's in the cache -- this gives you a way of faking files existing on other servers at the URL of your choice, and as long as they're in the cache you'll get away with it.
1. you visit evil.example and the browser stores evil.js with the cache key "foo".
2. you visit victim.example which has an XSS vulnerability, but victim.example thinks it is safe because it uses Content Security Policy and does not allow inline scripts or scripts form evil domains.
3. the XSS attack is loading <script src=www.victim.example/evil.js hash=foo>
4. the browser detects that "foo" is a known hash key and loads the evil.js from cache. Thinking that the file is hosted on victim.example - when the file is in fact not even present.
5. the evil.js script executes in the context of victim.example, even though they use a Content Security Policy to prevent XSS from being exploitable.
It seems like the problem is that you need to verify that the file actually exists there with the specified hash, but that isn't the same as having to download it. Is there a way to ask the server for just the hash of a file? You would still have the round trip to the server, but it would be a request for a 32 byte content hash rather than several orders of magnitude more data than that.
One of the replies to my similar post in the earlier thread [5] was from btrask who proposes a similar scheme, using a manifest placed in .well-known/, on the issue tracker for the W3C SRI spec [6]. The conversation is still ongoing, but see that for advantages and drawbacks, as well as other proposed solutions (and/or join the conversation!)
The problem is that www.victim.example/evil.js doesn't exist, and never did, but your browser won't know that if it's in the cache -- this gives you a way of faking files existing on other servers at the URL of your choice, and as long as they're in the cache you'll get away with it.
and from [2]:
0. evil.example hosts evil.js, <script src=evil.js integrity=foo>.
1. you visit evil.example and the browser stores evil.js with the cache key "foo".
2. you visit victim.example which has an XSS vulnerability, but victim.example thinks it is safe because it uses Content Security Policy and does not allow inline scripts or scripts form evil domains.
3. the XSS attack is loading <script src=www.victim.example/evil.js hash=foo>
4. the browser detects that "foo" is a known hash key and loads the evil.js from cache. Thinking that the file is hosted on victim.example - when the file is in fact not even present.
5. the evil.js script executes in the context of victim.example, even though they use a Content Security Policy to prevent XSS from being exploitable.
[1] https://news.ycombinator.com/item?id=10310594 [2] https://news.ycombinator.com/item?id=10311555 [3] https://news.ycombinator.com/item?id=10312333
(parts first posted here: https://news.ycombinator.com/item?id=13493407#13495482)