The reason onclick is disallowed is because it permits full JavaScript execution. An onlick attribute is ‘eval’d on click. If you can inject one into a page you get JavaScript execution. Hence, content security blocking - a rule served up on the page saying ‘nothing in this page is supposed to have onclick attributes. If you see one ignore it’.
These command attributes are not arbitrary JavaScript hooks. They tell inbuilt components to do inbuilt things. It doesn’t make sense for a content security policy to say ‘nothing on this page has commands, if you see something that does ignore it’, any more than it would make sense for a content security policy to say ‘nothing in this page is in bold, if you see something that says it wants to be displayed in bold ignore it’.
This makes sense, but it feels like the case is overstated... Is it really common for sites to disable their own onclick attributes? Is it just the case that the CSP rule disables onclick in the HTML, but first party scripts can then attach event handlers separately?
If you’re dynamically generating the HTML it’s safest to set the CSP to disable all inline scripts; you can permit only static scripts served from known good locations with valid sub resource integrity hashes.
What is to prevent command and commandfor from being included in future CSP rules for the same reason onClick is?