Bug 149000 - Some extensions triggers CSP violation reports
Summary: Some extensions triggers CSP violation reports
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Timothy Hatcher
Keywords: InRadar
Depends on:
Reported: 2015-09-09 07:10 PDT by Nicolas H.
Modified: 2022-08-12 14:34 PDT (History)
17 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas H. 2015-09-09 07:10:24 PDT
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)
Comment 1 silverwind 2017-03-18 05:59:33 PDT
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:

Comment 2 silverwind 2017-03-18 07:08:05 PDT
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
Comment 3 Sam Deane 2018-01-10 04:07:30 PST
It appears that the spec now says "may" and not "should", so the current behaviour may not violate the letter of the law.


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.
Comment 4 Alexander Ljungberg 2018-08-30 03:11:47 PDT
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.
Comment 5 Radar WebKit Bug Importer 2020-07-08 07:56:11 PDT