Bug 1685123 docs for implementation of WebEx manifest sandbox#44709
Bug 1685123 docs for implementation of WebEx manifest sandbox#44709rebloor wants to merge 1 commit into
Conversation
github-actions
Bot
added
Content:Firefox
|
@Rob--W is inclusion of the example on the manifest page sufficient, or would you prefer to pull that out into a separate "how to" page? |
|
Preview URLs (5 pages)
External URLs (1)URL:
|
| ); | ||
| }); | ||
|
|
||
| window.addEventListener("message", (event) => { |
There was a problem hiding this comment.
As security best practice, always validate the source of the message:
| window.addEventListener("message", (event) => { | |
| window.addEventListener("message", (event) => { | |
| if (event.origin !== location.origin) { | |
| // Reject messages not coming from the extension. | |
| // Although the popup origin is opaque, | |
| // location.origin still reflects the true URL of | |
| // the resource in the extension package. | |
| return; | |
| } |
| `sandbox.js` listens for messages from the popup, renders a template using the sandboxed library, and posts the result back: | ||
|
|
||
| ```js | ||
| window.addEventListener("message", (event) => { |
There was a problem hiding this comment.
Below I am showing a concrete snippet to validate messages. Can you include that here too, and prominently mention a link to the security-relevant best practices at https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#security_concerns
Ideally we should have a dedicated section on this manifest page that clarifies how this feature should be used:
- messages between the extension and sandboxed page should be strictly validated, with link to https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#security_concerns
- don't execute untrusted code. Although the extension does not have access to privileged APIs, the extension URL may identify the use of the extension and be abused for fingerprinting purposes.
- don't use sandboxed pages with a relaxed CSP if your only objective is the use of WebAssembly. Instead, add
'wasm-unsafe-eval'to the extension'scontent_security_policyinstead.
|
|
||
| > [!NOTE] | ||
| > Chrome has a more permissive default sandboxed pages CSP: `sandbox allow-scripts allow-forms allow-popups allow-modals; script-src 'self' 'unsafe-inline' 'unsafe-eval'; child-src 'self';`. |
There was a problem hiding this comment.
This is incorrect; Chrome's docs currently state this but it is inaccurate.
Chrome's current default sandbox CSP is sandbox allow-scripts; script-src 'self'
following discussion at w3c/webextensions#98
and explicitly stated at https://docs.google.com/document/d/1m82BcCPWDTEzy1R6gbCbUwe-ma-bCTTF_JwRnt3O_IA/edit?tab=t.0#heading=h.oj1dbds5d377
| > [!NOTE] | |
| > Chrome has a more permissive default sandboxed pages CSP: `sandbox allow-scripts allow-forms allow-popups allow-modals; script-src 'self' 'unsafe-inline' 'unsafe-eval'; child-src 'self';`. |
| <!-- ### Removals --> | ||
|
|
||
| <!-- ### Other --> | ||
| - Adds support for the [`sandbox`](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/sandbox) manifest key, enabling extensions to designate pages that load with an opaque origin. A sandboxed page can use `eval()` and similar constructs that are otherwise blocked by the extension's [content security policy](/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy). The sandboxed page can only access WebExtension APIs or the rest of the extension through {{domxref("Window.postMessage()")}}. ([Firefox bug 1685123](https://bugzil.la/1685123)) |
There was a problem hiding this comment.
| - Adds support for the [`sandbox`](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/sandbox) manifest key, enabling extensions to designate pages that load with an opaque origin. A sandboxed page can use `eval()` and similar constructs that are otherwise blocked by the extension's [content security policy](/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy). The sandboxed page can only access WebExtension APIs or the rest of the extension through {{domxref("Window.postMessage()")}}. ([Firefox bug 1685123](https://bugzil.la/1685123)) | |
| - Adds support for the [`sandbox`](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/sandbox) manifest key, enabling extensions to designate pages that load with an opaque origin, without direct access to extension APIs. A sandboxed page can use `eval()` and similar constructs that are otherwise blocked by the extension's [content security policy](/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy). ([Firefox bug 1685123](https://bugzil.la/1685123)) |
| <html lang="en"> | ||
| <head> | ||
| <meta charset="utf-8" /> | ||
| <script src="templating-library.js"></script> |
There was a problem hiding this comment.
Is this intended as a placeholder example? The example on the page itself does not run because the definition of the file is missing.
| Sandboxed pages are loaded with a unique, opaque origin, instead of the extension's usual `moz-extension://` origin. As a result: | ||
|
|
||
| - Sandboxed pages can't access [WebExtension APIs](/en-US/docs/Mozilla/Add-ons/WebExtensions/API). The `browser` and `chrome` global objects are not available. | ||
| - Sandboxed pages can't access, and can't be accessed by, other pages in the extension, except by using {{DOMxRef("Window.postMessage()")}}. |
There was a problem hiding this comment.
This statement is too firm. There are other ways to communicate. Suggested edit:
| - Sandboxed pages can't access, and can't be accessed by, other pages in the extension, except by using {{DOMxRef("Window.postMessage()")}}. | |
| - Sandboxed pages can't access, and can't be accessed by, other pages in the extension, except indirectly by communicating through APIs such as {{DOMxRef("Window.postMessage()")}}. |
|
|
||
| Use the `sandbox` key to designate one or more of an extension's pages as **sandboxed pages**. | ||
|
|
||
| Sandboxed pages are loaded with a unique, opaque origin, instead of the extension's usual `moz-extension://` origin. As a result: |
There was a problem hiding this comment.
Link "opaque origin" to https://developer.mozilla.org/en-US/docs/Glossary/Origin#opaque_origin
Also add a bullet point mentioning that web platform APIs bound to the origin are unavailable. For some examples, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/sandbox#allow-same-origin
|
|
||
| This makes the `sandbox` key useful for including a third-party library that relies on `eval()` or `new Function()`, such as some templating engines: load the library in a sandboxed page, and use `postMessage()` to send it data from, and return results to, the rest of the extension. | ||
|
|
||
| ## Manifest V2 syntax |
There was a problem hiding this comment.
Wouldn't it be less confusing if we:
- declare one overview, and emphasize for the sandbox.content_security_policy key that it is MV2 only
- at that description, point to the section on content_security_policy.sandbox (on the same page) for the MV3 syntax
- note that the
content_security_policy.sandboxis MV3-only, and that for MV2 the other key has to be used?
This would enable us to add new manifest keys to sandbox without being forced to duplicate that documentation in two sections. I anticipate that we will likely have a new manifest sub key in sandbox as part of https://bugzilla.mozilla.org/show_bug.cgi?id=2053336
| sandbox allow-scripts; script-src 'self'; | ||
| ``` | ||
|
|
||
| This isolates a sandboxed page from the rest of the extension, but doesn't allow `eval()` or similar constructs. To permit these, include `'unsafe-eval'` (or `'wasm-unsafe-eval'` for [WebAssembly](/en-US/docs/WebAssembly)) in the `script-src` directive of a custom policy. |
There was a problem hiding this comment.
| This isolates a sandboxed page from the rest of the extension, but doesn't allow `eval()` or similar constructs. To permit these, include `'unsafe-eval'` (or `'wasm-unsafe-eval'` for [WebAssembly](/en-US/docs/WebAssembly)) in the `script-src` directive of a custom policy. | |
| This isolates a sandboxed page from the rest of the extension, but doesn't allow `eval()` or similar constructs. To permit these, include `'unsafe-eval'` in the `script-src` directive of a custom policy. |
Dropped wasm mention to avoid giving the wrong impression that wasm requires sandboxed pages.
|
|
||
| A sandboxed page can be given a more permissive [content security policy (CSP)](#content_security_policy_for_sandboxed_pages) than the rest of the extension. This includes a CSP that permits [`eval()`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval) and similar constructs that are blocked by an extension's [default content security policy](/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy#default_content_security_policy). Because a sandboxed page can't use WebExtension APIs or reach the rest of the extension directly, this can be done without weakening the security of the extension as a whole. | ||
|
|
||
| This makes the `sandbox` key useful for including a third-party library that relies on `eval()` or `new Function()`, such as some templating engines: load the library in a sandboxed page, and use `postMessage()` to send it data from, and return results to, the rest of the extension. |
There was a problem hiding this comment.
The framing of template engine is likely copied from Chrome. Although that was a motivating factor back then (10+ years ago), it is hardly a relevant considerations now. These days such libraries are mostly designed to work even with a strict CSP. Let's drop the mention of templating libraries (the general reference to eval/Function are sufficient).
4 participants
Description
Add details of the
sandboxmanifest key for Bug 1685123 "implement manifest sandbox support". In addition to the new manifest key page forsandbox, the changes include:content_security_policykey page to link to the newsandboxmanifest key page.sandboxmanifest key to the list of manifest keys.Related issues and pull requests
Parallel BCD updates in mdn/browser-compat-data#30031