I like the original CSP and while I don't take issue with them adding these extensions both seem quirky to use...<p>So with nonce based whitelisting, you really need your JavaScript blocks generated from code behind/a framework. Since they have to be rotated every single request, it would only really be efficient to utilise it when the entire page is re-generated every request already.<p>With the hash blocks, first off generating the hashes will be pure hell without amazing tooling, and also the devil is really in the details for exactly what the hash represents (e.g. the literal block as written, the block trimmed, the block with all whitespace removed, etc).<p>If it is the literal block as written then that is going to break a LOT. A single extra whitespace? Broken. The source changed from UNIX to Windows newlines, broken. ASCII to UNICODE conversion? broken. Code style applied? Super-broken, and so on.<p>So with both nonce AND hash based approach it seems like it has to be totally automated, and now you've effectively turned all HTML pages from "static" content into dynamic content (since in both case you're likely generating the CSP elements each "compile").<p>Honestly these seem like such a PITA to use, that they don't really make it easier for existing code bases to move to CSP, since a lot of work to find and modify every single JavaScript block (and then the CSP block) would be quite an undertaking. If I was going to do that I'd just move it all to *.JS files and use CSP 1.0.
One of the reasons preventing XSS is important is preventing data exfiltration.<p>One of the things I see a lot of people doing is whitelisting in their CSP rules 3rd party APIs like Google Analytics. Well...these can be used to exfiltrate data too...<p>There are a TON of 3rd party APIs that can't be safely whitelisted with CSP. A whitelist for GA or Stripe on all pages means you are poking holes in your CSP....And poking holes in anything usually has issues associated with it.