[tunetheweb]

OP here and I disagree. Implementing a CSP for a page is hard (given the many different browsers), implementing it for a site is really hard! And yes it does pretty much need to be "domain level" to be effective.

It's easy to test if a password algorithm change fails, not so much for CSP. And the reporting options are next to useless because they are so noisy.

That's not to say people shouldn't implement CSP - it's a great option (now - less so in 2015 when this post was written). But they shouldn't just copy and paste a CSP policy from a random blog post they found, get an A+ on a security scanning tool and feel proud, without realising that they may have broken part of their website or implemented a pointless CSP. That was intention of this post and apologies if it read as "don't use then cause they are hard".

[Cpoll]

> It's easy to test if a password algorithm change fails, not so much for CSP.

Probably a bad example, because the former is server-side. But why is CSP harder to test than any other client-side change, like rewriting your login page/component?

> And yes it does pretty much need to be "domain level" to be effective.

I meant to say that you can add it as a XSS prevention to example.com/app/ and not worry about example.com/static/ or example.com/blog/

[tunetheweb]

> But why is CSP harder to test than any other client-side change, like rewriting your login page/component?

Maybe not so much now. But when I wrote that post there were lots of bugs and missing features across the various browsers (examples in the post). It was early days for CSP and it’s got better since (hence why I now do recommend CSP), but regardless CSP is a complex technology and tough to get right. Each page and each browser might have its own CSP requirements (e.g. when polyfills are included on a bad for example).

> I meant to say that you can add it as a XSS prevention to example.com/app/ and not worry about example.com/static/ or example.com/blog/

Then your cookies are at risk. Yes cookies can be scoped to a path, but few do that. And they can be made HttpOnly which is more common, but still not used anywhere near enough (8.31% of cookies - https://github.com/mikewest/http-state-tokens/blob/master/RE...). Additionally if you have a vulnerability on /static/ then you can hijack the app link or login link to send users to badexample.com or similar when they want to login to the app.

It will still offer some protection if only on /app/ and is better than nothing, but still preferable to have it on the whole domain. It’s like HTTPS - having it on just one page is an anti-pattern that shouldn’t be used anymore.