Inconsistency: CSP sandbox directive and content script and style injection into pages

[bershanskiy]

Chrome injects content scripts and styles into contexts with CSP directive sandbox, while Firefox and Safari do not.

Philosophically, since typically extension resources are exempt from other CSP directives like script-src, style-src, and other, browsers should exempt extension resources from sandbox as well. However, two browsers have this "bug" and only one is "correct", which is not typical.

Testing details

Real-world URL

This issue was initially discovered on the following URL: https://ci.ubports.com/job/docs.ubports.com/job/PR-508/7/artifact/_build/html/..index.html

This originally came up at: https://github.com/darkreader/darkreader/issues/9861

Minimal demo

Chrome

When a tab is opened, it shows only red Script ran text. Text comes from script, while red color comes from injected style.

Safari and Firefox

Extension has no effect on the tab.

Code

NodeJS Express server:

'use strict';

const express = require('express');

const app = express();

app.get('/index.html', (req, res) => {
  res.set('content-security-policy', 'sandbox');
  res.send('Hello world!');
});

app.listen(8000);

Extension manifest.json:

{
  "manifest_version": 2,
  "name": "Demo",
  "description": "Demo",
  "version": "1.0",
  "content_scripts": [
    {
      "matches": ["*://*/*"],
      "js": ["script.js"],
      "css": ["style.css"]
    }
  ]
}

Extension content script script.js:

document.body.innerText = 'Script ran';

Extension injected style style.css:

body {
  color: red;
 }

[Rob--W]

FYI: this issue is known and I have co-designed an API with Chrome to control the behavior in a predictable way. Details are linked from https://bugzilla.mozilla.org/show_bug.cgi?id=1411641#c43

Firefox has not implemented it yet (but it's tracked in that bug).

Chrome has implemented it in (again detail in the bugs linked from the bug):

• MV3 content scripts, as the match_origin_as_fallback option.
• An undocumented option in scripting.registerContentScripts (as matchOriginAsFallback).
• NOT in tabs.executeScript nor in scripting.executeScript
• Chrome's implementation is not public yet. The API partially exists but it is not documented.

[tophf]

NOT in tabs.executeScript nor in scripting.executeScript

AFAICT from the source code, scripting.executeScript always uses matchOriginAsFallback mode.

[Rob--W]

I have recently implemented support for content script injection in sandboxed documents, and match_origin_as_fallback to match about:blank, about:srcdoc, data: and blob: in Firefox 128.

In cases where the URL contains a meaningful representation of the document, i.e. http(s) and file:-schemes, we use that URL for matching. Even if the origin is opaque due to the use of CSP sandbox by the web page.

match_origin_as_fallback supersedes match_about_blank:

• match_about_blank: true only matches if the document is about:blank or about:srcdoc and the opener document'd URL matches the matches pattern. The document does not match if the frame is sandboxed.
• match_origin_as_fallback: true matches if the origin/path cannot be determined from the URL (i.e. http(s)/file does not require this flag) but the opener document's origin matches the origin as specified in the "matches" pattern. If the opener has an opaque origin (serialized as "null") then the precursor of that origin is used, that is the non-opaque origin that created the opaque origin. This currently applies to the data:, about:blank+srcdoc and blob:-URLs (filesystem: is not supported in Firefox because it is a Chrome-only protocol). Because the origin is used for matching, the path is empty. This means that content script declarations with a non-wildcard path won't match. Chrome refuses to load extensions without a wildcard path in matches, Firefox doesn't trigger an error but naturally the script won't be injected.

[oliverdunk]

match_origin_as_fallback and associated sandboxed document behavior is already supported in Chrome :)