Talk to @arturjanc.
The attacker can add a full-page overlay so any click will trigger the `onclick' EH; it's hard to prevent it, IMO not worth trying.
-
-
Removing user interaction makes attacks easier. I have more examples, but twitter is not suitable for explaining those.
-
I agree
and would definitely encourage you to comment on the spec (either one of the GitHub issues linked above, or just start a new one!) -
If the intention is to automatically apply this, how can you possible address the warning in the spec 8.3? https://w3c.github.io/webappsec-csp/#unsafe-hashed-attributes-usage …
-
Applying this to static pages would bless inline scripts present in those pages; on many sites such content is separate from the main app...
-
In those cases the scripts often do not invoke functions which trigger interesting behavior (in our use cases it's often just analytics).
-
I hope we can agree that this is not infallible, but it is a significant tightening of the "no restrictions at all" model of 'unsafe-inline'
-
For apps which are able to easily refactor their inline event handlers, the answer is: just do it. 'u-h-a' is for the 90% who can't/don't.
-
It also unblocks apps using widgets incompatible with CSP. Now you can often just bless their event handlers and you fix 'unsafe-inline'.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.