[BUG] FirefoxMV2: privileged api leakage due to same-origin

[cyfung1031]

• Follow up on [MV2] 针对 WebExtensions API Changes (Firefox 149-152) 做修正 #1448
• Temporary workaround by PR fix(mv2): [temporary workaround] privileged api leakage due to same-origin #1469

---

Problem Description

cc @Rob--W

We need Firefox support for extension sandbox manifest behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1685123

• Also see Allow to create sandboxed iframes in background script of addons w3c/webextensions#637

---

Firefox MV2 Security Vulnerability: privileged API leakage due to same-origin sandbox

In order to continue supporting Firefox, ScriptCat still needs to maintain the old Firefox MV2 runtime.

After #1448, the MV2 sandbox iframe had to use:

sandbox="allow-same-origin allow-scripts"

This was necessary for Firefox MV2 compatibility, but it also means the userscript execution document becomes same-origin with the extension document.

Because of that, "background scripts" may be able to access privileged extension globals directly, or escape through same-origin window references such as:

chrome
browser
window.chrome
window.browser
parent
top
frameElement
frameElement?.ownerDocument.defaultView
window.frameElement?.ownerDocument.defaultView

This is not expected. Background/scheduled scripts should only access ScriptCat-provided APIs and should not be able to reach privileged WebExtensions APIs directly.

We are looking for Firefox sandbox manifest support / MV3 sandbox behavior as the proper long-term solution. Until then, #1469 adds a temporary runtime workaround.

---

Why this matters

A background userscript should run in an isolated userscript environment.

If the userscript can access chrome or browser, it may bypass ScriptCat’s GM API mediation layer and interact with extension-level WebExtensions APIs directly.

If it can access parent, top, or frameElement.ownerDocument.defaultView, it may also obtain a reference back to the privileged extension window.

This is especially risky in Firefox MV2 because the same-origin sandbox workaround weakens the expected isolation boundary.

---

Reproduction Script

// ==UserScript==
// @name         New Userscript M9NO-1
// @namespace    https://docs.scriptcat.org/
// @version      0.1.0
// @description  try to take over the world!
// @author       You
// @background
// ==/UserScript==

const c1 = typeof chrome === "undefined" ? undefined : chrome;
const c2 = typeof browser === "undefined" ? undefined : browser;

console.log("sandbox", c1, c2);
    
return new Promise((resolve, reject) => {
    // Your code here...
    resolve();

});

---

Expected Behavior

In a background userscript sandbox, privileged browser extension APIs should not be exposed.

---

Actual Behavior

In Firefox MV2, because the sandbox iframe is same-origin with the extension document, the background userscript may observe privileged globals.

This means the userscript can potentially access the privileged extension execution environment.

---

Chromium MV3 / ScriptCat 1.3.2

Expected behavior: privileged APIs are not exposed to the userscript sandbox.

---

Firefox MV2 / ScriptCat 0.16.15

Actual behavior: privileged APIs / privileged references may be visible from the background userscript sandbox.

---

Reproduction Steps

1. Install/run ScriptCat Firefox MV2.
2. Create a background userscript using the reproduction script above.
3. Open the background script console/log output.
4. Check whether privileged APIs in chrome or browser are exposed.
5. Compare with Chromium MV3 behavior.

---

ScriptCat Version

Affected:

• Firefox MV2 / ScriptCat 0.16.15

Reference behavior:

• Chromium MV3 / ScriptCat 1.3.2

---

Additional Information

This issue is caused by the Firefox MV2 same-origin sandbox compatibility workaround.

The long-term solution should be proper sandbox manifest support / unprivileged extension sandbox behavior in Firefox.

Until then, ScriptCat needs to keep a Firefox MV2-specific runtime mitigation.