CSP violations for inline scripts should be reported when the code would have been actually executed otherwise.
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
People
(Reporter: ma1, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-backlog3])
I'm not sure about which is the expected/desirable behavior and/or if it's actually specified anywhere, but while investigating https://bugzilla.mozilla.org/show_bug.cgi?id=1650305 I've noticed a discrepancy in how, and especially when, violations are reported in Firefox vs Chromium.
In order to appreciate the difference, you just need to open https://webdriver-herald.herokuapp.com/ with NoScript enabled and no further special settings (i.e. herokuapp.com being denied script execution by NoScript via CSP).
On that page https://webdriver-herald.herokuapp.com/, where there are 8955 onmouseover and 8955 onmouseout inline attributes, Firefox fires 17910 securitypolicyviolation events and, if required (like in NoScript < 11.0.33rc1), sends 17910 CSP violation reports all at once while the page is loading.
No wonder that any code responding to these events/reports is gonna put the system on its knees.
Chromium just creates 1 report while the page is loading (for an external script), then further reports only when you actually move the mouse on the page, as soon as the onmouse* handlers are actually triggered.
Obviously from NoScript's standpoint Firefox's behavior is defective, because it easily lends itself to performance issues and even DOSes.
However I can also see the argument for reporting everything at compile time. But perhaps there should be at least some way to filter and/or coalesce the reports?
|
||
Comment 1•4 years ago
|
||
FWIW, the Firefox behaviour is much nicer when adding CSP to an existing site (especially without automated tests) as you don't need to exercise all code paths in order to fix CSP violations.
|
||
Comment 2•4 years ago
|
||
We detect inline scripts in the JS compiler--as the page is loading--and don't really know otherwise. We could certainly suppress the events during load (if the page isn't loaded, can it catch the events? I guess if the error handler is already loaded) and maybe just put them on the console for the developer case MattN mentions?
Description
•