2 ms·
My biggest frustration with CORS is that none of it is technically needed. We could have skipped the whole thing if subresource integrity (SRI) had been implem
by zackmorris 8y ago
My biggest frustration with CORS is that none of it is technically needed.
We could have skipped the whole thing if subresource integrity (SRI) had been implemented much earlier, possibly in HTTP 1.0, which makes its absence one of the great blunders of the web:
https://en.wikipedia.org/wiki/Subresource_Integrity https://en.wikipedia.org/wiki/Subresource_Integrity
On top of that, SRI would have allowed us to use standardized versions of libraries like jQuery and Angular from their home URLs, which would have reduced the initial load size of single page applications by megabytes via caching (because those libraries would have already been loaded long ago from other sites).
Which naturally would have led to content-addressable data, Merkle trees, etc which would have given us performance more in line with BitTorrent (at least for commonly used files/scripts).
On top of that, I'm not completely convinced that CORS avoids IP address spoofing, DNS poisoning etc. It probably needs to piggyback on HTTPS to be sure, which is a common way to avoid that can of worms so I can't criticize it too badly for that.
I should add that SRI has one critical flaw in that it's still vulnerable to user-posted content (like comments) trying to embed a <script> tag containing a fake hash in the body. I haven't been deep enough in SRI to know if it's possible to specify hashes off page, maybe someone knows? Otherwise we may still need something like CORS, or better yet, something that blocks further includes altogether rather than conflating the issue with focusing on where they came from.