Use https by default in requests from extensions, e.g. via extension CSP
Categories
(WebExtensions :: General, enhancement, P2)
Tracking
(firefox109 fixed)
Tracking | Status | |
---|---|---|
firefox109 | --- | fixed |
People
(Reporter: robwu, Assigned: mixedpuppy)
References
Details
(Keywords: dev-doc-complete, Whiteboard: [wecg][addons-jira])
Attachments
(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.
Example:
- 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: 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.
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:]".
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
Assignee | ||
Updated•2 years ago
|
Comment 3•2 years ago
|
||
Backed out changeset 08a9aacc9f0c (Bug 1797086) for causing mochitest failures on test_ext_dnr_upgradeScheme.html.
Backout link
Push with failures <--> 5
Failure Log
Comment 5•2 years ago
|
||
bugherder |
Documentation update in upgrade-insecure-requests added to default MV3 CSP #23114
Reporter | ||
Comment 7•2 years ago
|
||
(clearing old needinfo; I've already started the documentation review on https://github.com/mdn/content/pull/23114#pullrequestreview-1229763904 )
Description
•