[jrpt]

I didn't downvote you but this site is very downvotey for anything that doesn't fit the hivemind. The downvotes on Dropbox's first post are infamous.

You're absolutely right that CSP and SRI are good in theory but fail in practice.

For CSP, it's too difficult to implement a secure CSP, especially without breaking your site. I know companies where it took over a year to implement their CSP. And then, at the end of the day, it's really hard to do securely. Research has found most CSPs are insecure. For example, the posted blog's CSP is: default-src * data: 'unsafe-eval' 'unsafe-inline' But even CSPs that look like they're trying to be secure contain subtle insecurities.

Even trusted domains you might put in your CSP can be used in untrusted ways. For example, this blog post uses Gravatar. Did you know that Gravatar has an optional "default image URL" that can be used for data exfiltration even on sites with secure.gravatar.com in their CSP? It's because Gravatar will proxy the request to fetch the default image if it doesn't recognize the email. https://en.gravatar.com/site/implement/images/ So you may think you've done everything correctly and have a good CSP but in reality it's really hard to do securely.

SRI isn't practical for third party resources that are expected to change over time, which is actually most third party resources. For example, a chat script like Intercom will change when someone from marketing makes a change that affects its frontend settings. This may be changing some text or coloring. You can use SRI for something like a specific version of jQuery, but not for most of the products people are relying on that have more dynamic functionality.