So, getting back to what I don't get about CSP, I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework.
Brittleness: CSP disables <script> tags and all the script element attributes. Almost every major website in the world uses these in some form today. Both CSP and "anti-XSS" features do server-side policy about what parts of a page can have scripts, but the "anti-XSS" features are far more flexible.
I don't see how anyone's more likely to use a new policy specification language better than they are going to use a toolkit designed for their own web framework.
This can be an http header, so an admin or senior can configure the whitelist once at the server layer and everyone in the org reaps the benefit, even if your development toolkit has problems of its own.
CSP disables <script> tags and all the script element attributes.
I don't do much front-end work, so correct me if I'm way off, but I was under the impression that the only reason to use script elements today was to either load your own scripts or to hack around the same-origin policy to load 3rd party scripts. That use case still works under CSP, as long as the site you're loading from is in the whitelist.
That's a really naive view of how app development and deployment works, so I'll sum my response to it up with, "the admin who adds the header that breaks the Javascript in a major application is going to be fired within a single digit number of Unix timeslices of the change going live."
The problem with this stuff is that it requires virtually top-to-bottom surgery on real world apps. It is another naive view of applications that says that the dangerous inputs all come from form arguments.
Wait, what? Of course an admin wouldn't just turn it on out of the blue one day, and of course that would be really, really stupid, but admins on the edge are responsible for stuff like this all the time. Turning on compression, setting up firewall rules, configuring caches.
Companies serve old applications, companies serve applications built on different platforms, companies get caught without the resources to rewrite insecure applications that pay the bills. You really think this is something that an ops team wouldn't love to have in its toolbox, to use as needed and where appropriate?
The problem with this stuff is that it requires virtually top-to-bottom surgery on real world apps.
If you can't use it in your app or environment without a huge rewrite, then don't. If you can, then it's gravy.
It is another naive view of applications that says that the dangerous inputs all come from form arguments.
I never said or implied they did, and that's not the only threat this proposal addresses.
The difference between CSP and compression, firewall rules, and caching are that CSP alters the way the application works, and the others don't. I've seen drama just in getting modsecurity deployed, and modsecurity is much less intrusive than CSP.
Brittleness: CSP disables <script> tags and all the script element attributes. Almost every major website in the world uses these in some form today. Both CSP and "anti-XSS" features do server-side policy about what parts of a page can have scripts, but the "anti-XSS" features are far more flexible.