3 ms·
Why require CORS? What good is that, here? If you're a malicious CDN, you'll just not support CORS and so no one can use this to protect themselves. If the C
by emn13 11y ago
Why require CORS? What good is that, here? If you're a malicious CDN, you'll just not support CORS and so no one can use this to protect themselves. If the CDN is benign but gets hacked, this just leaves the (unlikely but possible) option of the hackers breaking CORS, waiting for the inevitable "I guess I'll just disable SRI", and then altering the subresource.
Requiring CORS simply makes security more difficult to achieve.
- bugmen0t 11y agoThe browser must not know the content (or the hash of the content) of files on your intranet (or any other domain that is not the one you are visiting right now.) See https://annevankesteren.nl/2015/02/same-origin-policy https://annevankesteren.nl/2015/02/same-origin-policy and http://w3c.github.io/webappsec/specs/subresourceintegrity/#cross-origin-data-leakage http://w3c.github.io/webappsec/specs/subresourceintegrity/#c...
- emn13 11y agoIf the hash functions are secure, the only way for this to leak information is if the attacker can make good guesses as to what the resource is a priori, and then use this to verify it. Fair enough, that's some information leakage, but it's certainly not easy to exploit. Normal cross-origin limitations still apply, so you'd need to get creative to even get the information in the first place, and if you can, it's not clear what this adds over a timing attack. I'm still a little skeptical such a heavy handed restriction is necessary to maintain the current level of security; but then again - why take the risk?