Inconsistency: custom content_security_policy browser restrictions

[carlosjeurissen]

Background

To make the extension platform more secure, browser vendors restrict the freedom webExtensions have in defining a custom content_security_policy. This comes in several forms.

1. By restricting what directives / values extensions are allowed to have. If an extension doesn't meet the requirements, the extension won't load.
2. By ignoring specific CSP values as a way to protect the users.
3. By not allowing extensions with specific CSP configuration to be submitting to webExtension stores.
4. By not allowing specific CSP configuration in the review process for webExtension store submissions.

Inconsistencies

The restrictions present differs between browsers, extension stores, manifest_versions and context (extension_pages, content_scripts, sandbox). For example, Chromium doesn't accept external scripts to be defined in script-src in MV3. Safari doesn't allow one to use wildmarks as src matches see issue. And Firefox doesn't support report-sample and strict-dynamic see issue.

In addition, the issues raised in webExtension store reviews differs per store. For example, in the past some stores rejected submissions when a webExtension tried to enforce a stricter CSP than default, as it was wrongly interpreted as making the extension less secure.

Goals

1. Add clear documentation what all the limitations and restrictions are for each browser, store, manifest_version, and extension context.
2. Make the restrictions the same across stores and browsers as much as possible.
3. Create proposals which improve the current situation. Like the two proposals down below.

Proposal 1

Instead of the 4 ways restrictions could be applied as specified above, allow any CSP to load and be submitted. However raise warnings and ignore specific configuration based on what restrictions should apply. This allows one to keep a single code base between browsers with different restrictions. This could be accompanied by proposal 2. This would also allow other browsers to use specific stores yet not have to enforce all CSP restrictions this store wants to apply to extensions.

Proposal 2

Instead of restricting what a CSP value can be. Have a restrictive CSP which is always present to the default or custom defined CSP of the user. As designed by the specs, two CSP can be applied at the same time, and the most restrictive in each directive is applied.

One could for example consider having a secondary CSP set to default-src: 'none' to force users to define each directive themselves so it's very clear what resources an extension uses and to reduce potential attack surfaces.

Another example is a secondary CSP set to script-src-attr 'none' to prevent inline scripting.

This would make it more clear and potentially technically easier to implement specific restrictions.