1864284 - Allow localhost in MV3 CSP to allow connecting to local dev servers

Status: NEW

(WebExtensions :: Untriaged, enhancement, P2)

Description

[aaronklinker1]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

Create a manifest.json with the following content:

{
  "manifest_version": 3,
  "name": "example",
  "version": "1.0.0",
  "content_security_policy": {
    "extension_pages": "script-src 'self' 'wasm-unsafe-eval' http://localhost:3000; object-src 'self';"
  }
}

Then load the extension into Firefox.

Actual results:

After loading the the extension, a warning showed up:

"Reading manifest: Error processing content_security_policy.extension_pages: ‘script-src’ directive contains a forbidden http: protocol source"

Expected results:

Firefox should allow adding localhost and 127.0.0.1 to CSPs for temporary extensions.

For security reasons, MV3 is originally blocked all sources not included in your extension. However, Chrome added support for allowing localhost and 127.0.0.1 for unpacked extensions in v110 so dev servers like Vite and Webpack can host JS files during development, enabling features like HMR.

• Original discussion for Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1247690
• Patch allowing localhost and 127.0.0.1: https://chromium.googlesource.com/chromium/src/+/b81d6dcb2f2a89075b2bd8619b59bbf00994a01d

Firefox should allow the same for temporary extensions. It seems to have been explicitly removed from firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1789751

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (121.0a1/20231115214519), Beta (120.0/20231113165053) and Release (119.0.1/20231106151204) under Windows 10 x64 and Ubuntu 22.04 LTS.

Since it seems this feature has been explicitly and intentionally removed, I’ll mark this report as an Enhancement and not a defect.

Comment 3

[Rob Wu [:robwu]]

Given the amount of feedback (this bug, bug 1789751, bug 1790236, and other places), I'm leaning towards supporting the request here., by allowing localhost and 127.0.0.1 for temporarily loaded add-ons only. That would be consistent with Chrome, where I provided input that lead to their current implementation (https://github.com/w3c/webextensions/issues/98#issuecomment-1298964372).

I originally wanted to any remote URL, to allow blocking of http(s) loads in the extension process (bug 1767798). I think that it would still be acceptable to have the check, with an exception for localhost only (when there are any temporarily loaded add-ons).

Comment 4

[Alexander]

Any news on this?

It's practically impossible to develop extensions on firefox due to this issue. I have to use Chromium browser to develop. And manually building and loading is a pain.

Even Chrome is supporting this officially. Can this be fixed asap?