|
|
|
|
|
|
by Cpoll
2622 days ago
|
|
|
> 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/ |
|
|
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.