Inconsistency: Default content_security_policy

[carlosjeurissen]

Background

Currently no good documentation is present on what the default content_security_policy is for every context (extension_pages, content_scripts and sandbox). This is a must when composing a custom CSP, especially when default-src is not set.

Firefox documentation gives:
script-src 'self'; object-src 'self';
See: MDN Docs

Chrome documentation gives:
default-src 'self'; connect-src * data: blob: filesystem:; style-src 'self' data: 'unsafe-inline'; img-src 'self' data:; frame-src 'self' data:; font-src 'self' data:; media-src * data: blob: filesystem:;
See: Chrome Docs. However, this seems to only apply to the legacy Chrome Apps.

Also no info is present on what the default is in MV3 or if it differs from MV2.

Action items

• Have an overview of each default CSP in each context for each browser and manifest_version
• Streamline the default CSP across browsers

Proposals

1. To best showcase what an extension does, how it's permissions are used and to decrease the attack surface with security vulnerabilities, requiring default-src in custom CSP could be proposed.
2. Have a default CSP (either as replacement or in addition to the above default) which won't be overridden by the extension custom CSP which will function next to the custom CSP. This could make restrictions more understandable / technically implementable.

See also:

• Inconsistency: custom content_security_policy browser restrictions #99

[Rob--W]

The documentation that you've linked for Chrome is specific to Chrome apps, and the source code confirms that this is Chrome app-specific: https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/manifest_handlers/csp_info.cc;l=44;drc=2d18bf1fec6017d20ced5b6110fdbfc8a342ebb5

Extensions have a default CSP similar to Firefox: https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/manifest_handlers/csp_info.cc;l=33;drc=ce6c3b02c5cc847a3febdef23416e1ae7feaa9f9

[bradcush]

Linking this specific Chromium bug related to WASM support and the extension specific wasm-eval directive. https://bugs.chromium.org/p/chromium/issues/detail?id=1173354#c48 As mentioned, with the most recent updates in Chrome when run with the flag --enable-features=AllowWasmInMV3, wasm-eval can now be specified but WASM works as well now with no CSP specified whether the extension is run as MV2 or MV3.

[Rob--W]

Chrome has landed a patch that changed the default CSP to script-src 'self' 'wasm-unsafe-eval'; object-src 'self'; (https://bugs.chromium.org/p/chromium/issues/detail?id=1173354#c60).

Firefox is about to support 'wasm-unsafe-eval' too, but will only include 'wasm-unsafe-eval' in MV2's default CSP, and removes it from the MV3 CSP.

I have filed two follow-up bugs to work towards the resolution of the differences:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1766027
• https://bugs.chromium.org/p/chromium/issues/detail?id=1318922

P.S. As noted in the Chromium report, there is not that much point in requiring object-src, because plugin support has been dropped from browsers. We may as well remove object-src from the default CSP to clean up the platform.

[rdcronin]

Hi folks!

We're looking into this (Extension CSP) on the Chrome side to address a number of outstanding issues we have. I'd like to see if we can align with other browser vendors where possible.

I've written up a doc with a proposal here:
https://docs.google.com/document/d/1m82BcCPWDTEzy1R6gbCbUwe-ma-bCTTF_JwRnt3O_IA/edit#heading=h.uvfu5unrnahu

(World-viewable, feel free to request comment access.)

Please let us know what you think.

[carlosjeurissen]

@rdcronin Thanks so much! Good to see this! Can you grant comment access? (As far as I know requesting comment access directly in Google Docs is not possible at this moment)

[rdcronin]

We've had issues in the past with various spam when opening up comments to anyone on the web with the link — for anyone who wants access, go ahead and request edit access and I'll grant comment access to the email address from the request.

(Separately, @dotproto , can we create a WECG Google Group so that we can easily share docs with that alias?)

[dotproto]

@rdcronin, I started looking into this. I've created a Google Group, but I think I will need W3C assistance to populate and maintain the group's members. Reaching out now.

[rdcronin]

I've seen (and responded to) Rob's comments on the doc; does anyone else have concerns with the proposed approach?

[hanguokai]

The proposal document focus on script-src and object-src. I'm not very familiar with CSP. I would like to ask what are other CSP instructions, like font-src, img-src, style-src, frame-src, media-src?

PS: I see @dotproto created a google group and I am in it, but I don't see I have comment permission in that document.

[Rob--W]

The proposal document focus on script-src and object-src. I'm not very familiar with CSP. I would like to ask what are other CSP instructions, like font-src, img-src, style-src, frame-src, media-src?

I suppose that you are wondering why the document only mentions script-src and object-src? Does the documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/content_security_policy help?

In case it wasn't clear: the browser uses CSP in extensions to restrict remote code execution. In MV1 there were no restrictions. In MV2 insecure scripts (http:) were blocked, and remote code from eval and https were allowed via an opt-in, to protect the extension against XSS. In MV3 all remote scripts are blocked, no exceptions, to protect the user from unverified code.

Other CSP directives (img-src etc) aren't set because these do not govern privileged script execution. In #303 there is a proposal to use the CSP to restrict insecure schemes (http:).

[hanguokai]

Ok. So there aren't any other CSP restrictions other than remote script and (proposed) upgrade-insecure-requests.

[rdcronin]

Ok. So there aren't any other CSP restrictions other than remote script and (proposed) upgrade-insecure-requests.

Mostly correct. The minimum CSP is what would enforce the CSP restrictions, and is proposed to be:

script-src 'self' 'wasm-unsafe-eval' http://localhost:* http://127.0.0.1:*; object-src 'self';

This restricts scripts to the extension origin and localhost, allows wasm to be used, and restricts object-src to self (though note the object-src restriction is mostly obsolete, as mentioned in issue 204).

The upgrade-insecure-requests change would not be a restriction, per se, but rather a default (which could then be overridden by the extension).

[rdcronin]

Hi folks!

I think the only outstanding question here is one that Rob raised in the doc about whether allowing localhost / 127.0.0.1 as a script source should only be allowed for unpacked extensions. Since the main purpose here is development, the idea is that this would be sufficient to allow folks to use these locally-hosted scripts during the development process, while avoiding opening up any security concerns for packed extensions. Our question is whether this would be sufficient for localhost use cases or if this would still break a number of important flows. Does anyone have concrete examples of issues that would arise if we only allow localhost for unpacked extensions?

[hanguokai]

I agree with Rob, there is generally no need to load localhost scripts in extension pages. Could you scan localhost CSP in Web store extensions? (only browser vendors can do it)

[rdcronin]

We could scan it in the webstore, but if the propose in the comment above is reasonable, we can restrict it at the platform level, as well.

Since there haven't been any objects to this here, we'll proceed with that approach. We can relax it if necessary in the future.

[rdcronin]

@Rob--W , I'm going to tentatively move forward with the changes to sandboxed page CSP and allowing localhost in unpacked extensions, if there are no further concerns here.

[Rob--W]

@Rob--W , I'm going to tentatively move forward with the changes to sandboxed page CSP and allowing localhost in unpacked extensions, if there are no further concerns here.

Sounds good to me. The proposed minimum CSP (base CSP is the terminology used in Firefox) an default CSP look good. Other questions that I had are already noted in the document as follow-ups, so I see no blockers against proceeding as is.

One thing that I didn't mention before - the proposal currently lists object-src 'self' in the minimum CSP. I suppose that this is there to block the use of plugins in Chrome. Its presence prevents developers from using <object> and <embed> to load content, with the alternative being <iframe>. Do you intentionally want to block <embed> and <object>, or do you just want to block usage of plugins in extensions?

If you want to block plugins in extensions, then a platform-level way to block it independent of CSP can help with keeping the (minimum) CSP concise. I noted that in the last sentence at #204.

[carlosjeurissen]

@rdcronin Thanks for writing up the document!

MV3 CSP DOC: Technically, we could remove all requirements (since the minimum CSP will take hold). The disadvantage to this is that developers would not see an error if they specify a CSP that will otherwise be ignored. Because of this, we propose leaving the enforcement for other directives.

As in between option we can consider a warning instead of an error. This would give more freedom in future changes regarding the minimum extension CSP and allows browsers and browser versions to differ with their minimum extension CSP.

MV3 CSP DOC: The minimum CSP applied by the browser can be confusing to extension developers, since it is not supplied by them but the error is a generic CSP error. It would be nice if we could differentiate errors from the minimum CSP and the extension-provided CSP.

This would be very welcome for the overall web platform itself. Being able to see which of the potentially many CSPs set triggered a certain CSP error is very helpful in debugging CSP issues.

[hanguokai]

(I'm preparing a slide about Extension MV3)

Edit: add Firefox's CSP

Let me summarize the current state.

By default, if there is no explicit declaration of CSP, it is:

"content_security_policy": {
    // Chrome
    "extension_pages": "script-src 'self'; object-src 'self';",
    // Firefox
    "extension_pages": "script-src 'self'; upgrade-insecure-requests;",
    "sandbox": "..."
}

The minimum CSP (maximum allowable CSP by developers) is:

"content_security_policy": {
    // Chrome
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval' http://localhost:* http://127.0.0.1:*; object-src 'self';",
    // Firefox
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; upgrade-insecure-requests;",
    "sandbox": "..."
}

wasm-unsafe-eval and localhost need to be added manually by developers. localhost is only be allowed for unpacked extensions.

[Rob--W]

In Firefox, MV3's default CSP is script-src 'self'; upgrade-insecure-requests; - see #303 for rationale.

In Firefox, localhost cannot be allowlisted. Chrome intentionally supports localhost in the CSP in unpacked extensions only.

Firefox doesn't restrict object-src since it does not support plugins. Chrome has object-src 'self' in the default and minimum CSP as explained in #204.

[Rob--W]

On Firefox's end, we decided that we are willing to support localhost/127.0.0.1 scripts in temporarily loaded MV3 extensions (was already supported in MV2). Follow https://bugzilla.mozilla.org/show_bug.cgi?id=1864284 for progress.

[hanguokai]

@rdcronin Chrome has a worker-src bug, that I reported at https://crbug.com/1504703 . worker-src 'self' should prevent from using new Worker(a_blob_url). It works on Web pages, but doesn't work on extension pages at the moment.