|
|
|
|
|
by jfager
6099 days ago
|
|
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. |
|
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.