My real concern is, despite the fact that developers have the ability to set policies about what regions on the page can contain dynamic content, "policy" is generally too brittle to describe what people need to put on pages in real-world apps.
I understand how you could think that was what was involved, as I got the same impression from the article and also thought that was dumb. However, that's not what is going on. You shut down broad classes of functionality entirely, and are required to provide all legit Javascript through <script> tags, which furthermore must come from your whitelisted sources.
(Actually, there are some other modes too; consult the spec for details. However, I expect this is the one people will be talking about.)
The article isn't exactly wrong, but it doesn't accurately convey what is going on, either. Basically, if you can discipline yourself well enough to only use included files (which isn't a terrible style anyhow), then this allows you to ensure that you won't execute injected content.
Is this something that you should be correctly escaping? Yes, absolutely. I am a huge advocate of that in my workplace. But I would certainly take advantage of this extra layer of protection, too, rather than rely on everybody in my company getting it all absolutely right, all the time. The problem with something like escaping is that you make one little error and you lose everything. This goes a long way towards mitigating that.
I haven't done a lot of thinking about this, but it looks good; in general, voluntarily discarding privileges you don't intend to use is a good security practice.
Still, I might use it, contingent on broader support and some burn-in time to ensure that it doesn't somehow create some sort of huge hole itself.
Maybe, but not everyone's using those libraries, and those libraries may themselves have bugs or may be used incorrectly. Defense-in-depth, and all that.
"policy" is generally too brittle to describe what people need to put on pages in real-world apps
Just reading through the spec I linked to, I don't see what would be particularly brittle about it. Do you have an example of a real-world use case that this would hamper?
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.
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.
