149000 2015-09-09 07:10:24 -0700 Some extensions triggers CSP violation reports 2022-08-12 14:34:47 -0700 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=144830 https://bugs.chromium.org/p/chromium/issues/detail?id=233903 https://bugzilla.mozilla.org/show_bug.cgi?id=866522 InRadar P2 Normal --- 1 dante3333 timothy aljungberg andre ap bfulgham dak dante3333 dbates jan jberlin opendarwin sam sam timothy webkit-bug-importer webkit webkit webkit oldest_to_newest 1124613 0 dante3333 2015-09-09 07:10:24 -0700 Steps to reproduce the problem: 1. Create a page with a CSP policy (without putting style-src 'unsafe-inline') and with a report uri 2. Open the page 3. Use some extensions like Diigo, Evernote, etc. 4. a report is sent to report-uri What is the expected behavior? The extension should not trigger any CSP policy violation, according to wikipedia : browsers and add-ins should be exempt from CSP => https://en.wikipedia.org/wiki/Content_Security_Policy#Browser_add-ons_and_extensions_exemption What went wrong? A report is sent to report-uri with safari-extension:// as source, like blocked-uri: "safari-extension://com.evernote.safari.clipper-q79wdw8yh9" (which shouldn't be) The report_uri script gets a CSP violation. Example on one of my websites : { "csp-report": { "document-uri": "http://a11y.nicolas-hoffmann.net/tabs/", "referrer": "https://www.google.fr/", "violated-directive": "frame-src 'self' ", "original-policy": "default-src 'self'; script-src 'self' *.jquery.com ; style-src 'self' 'unsafe-inline' data: ; img-src 'self' data: ; frame-src 'self' ; report-uri /csp-parser.php", "blocked-uri": "safari-extension://com.wotservicesoy.wot-ff6ww26hl3" } } I don't know if it may help, the same bug is present on Blink: https://code.google.com/p/chromium/issues/detail?id=524356 (with a lot of more details) 1289272 1 webkit 2017-03-18 05:59:33 -0700 Please make extension exempt from a Site's CSP, similar to how Chrome and Firefox already do. The issue also affects userscript engines like Tampermonkey: https://github.com/Tampermonkey/tampermonkey/issues/296#issuecomment-222356524 1289273 2 webkit 2017-03-18 07:08:05 -0700 It's also specced that CSP should not interfere with extensions: Cite from https://w3c.github.io/webappsec-csp/#extensions: > Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets 1387604 3 sam 2018-01-10 04:07:30 -0800 It appears that the spec now says "may" and not "should", so the current behaviour may not violate the letter of the law. https://github.com/w3c/webappsec/commit/73963d509b20513a6f42b1e0839715aca8b578b0 It does however make it pretty hard (if not impossible) to implement a whole range of useful extensions which of necessity rely on script injection. It seems sensible to have a mechanism that would allow browsers to exempt extensions (perhaps on a per-extension basis). It then comes down to a matter of user-trust whether to allow each extension full access - which seems to be in keeping with the W3C intent. 1455189 4 aljungberg 2018-08-30 03:11:47 -0700 I'm also affected by this issue. I wrote a script to add some keyboard shortcuts to Phabricator and I inject it using Tampermonkey. Phabricator added a CSP header and it stops my extension from even loading. In my opinion, the best solution would be to allow extensions to do what they want (that's the purpose of extensions after all). The second best solution would be able to turn off CSP on a per site basis, say in Preferences. 1669748 5 webkit-bug-importer 2020-07-08 07:56:11 -0700 <rdar://problem/65223957>