Closed Bug 1797086 Opened 2 years ago Closed 2 years ago

Use https by default in requests from extensions, e.g. via extension CSP


(WebExtensions :: General, enhancement, P2)



(firefox109 fixed)

109 Branch
Tracking Status
firefox109 --- fixed


(Reporter: robwu, Assigned: mixedpuppy)



(Keywords: dev-doc-complete, Whiteboard: [wecg][addons-jira])


(1 file)

Extensions are expected to securely process user data (per add-on policies). It is currently not easy to verify this through the add-on review process.

Ideally, extensions should use https whenever possible, for example for API requests. There are however scenario's where this is not feasible, e.g. when extensions send requests to arbitrary URLs (e.g. user-defined, from web content, etc). With widespread adoption of https (over 80% of all websites using https, according to Let's Encrypt/Firefox telemetry), the vast majority of extensions do likely not need http: any more. With MV3 around the corner, where we can afford breaking changes, we can try to enforce the use of https: by default.

To have secure defaults while avoiding the loss of functionality, we could block http:-usage in the default CSP. Moreover, we can add the upgrade-insecure-requests CSP directive to automatically upgrade http:-URLs to https: for subresource requests. Extensions that need to make http:-requests for some reason can opt out of this behavior by overriding the default CSP in manifest.json.


  • Current MV2 CSP: script-src 'self' 'wasm-unsafe-eval' (see bug 1766027 comment 2 for details)
  • Current MV3 CSP: script-src 'self'
  • Proposed MV3 CSP: script-src 'self'; upgrade-insecure-requests
  • Or even: default-src 'self' https: data: blob: moz-extension: 'unsafe-inline'; script-src 'self'
    • Note: this is a mouth full. This is basically everything that CSP currently recognizes, minus sources that are already falling back to existing sources, e.g. 'unsafe-hashes' falls back to 'unsafe-inline'; 'unsafe-inline is included for inline styles.

Note: since upgrading https happens before the enforcement of CSP, we could just add upgrade-insecure-requests without other changes to the CSP. The only benefit of adding a default-src directive without http: is that it would be reported via the securitypolicyviolation event that developers can use to detect CSP violations. The disadvantage of adding default-src ourselves is that we would have to specify every feature controlled by CSP: It is not possible to write a CSP that says "only disallow http:", the only option is "only allow [whole list of sources minus http:]".

Whiteboard: [wecg]
Assignee: nobody → rob
Severity: -- → N/A
Priority: -- → P2
Whiteboard: [wecg] → [wecg][addons-jira]
Assignee: rob → mixedpuppy
Keywords: dev-doc-needed

Backed out changeset 08a9aacc9f0c (Bug 1797086) for causing mochitest failures on test_ext_dnr_upgradeScheme.html.
Backout link
Push with failures <--> 5
Failure Log

Flags: needinfo?(mixedpuppy)
Pushed by
add upgrade-insecure-requests to the base csp for MV3 r=robwu
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch

Documentation update in upgrade-insecure-requests added to default MV3 CSP #23114

(clearing old needinfo; I've already started the documentation review on )

Flags: needinfo?(mixedpuppy)
You need to log in before you can comment on or make changes to this bug.