1985652 - WebExtension-injected content will fail CORS checks when requesting other resources from the WebExtension, due to Firefox no longer using triggeringPrincipal for those CORS checks

Status: VERIFIED FIXED

(Core :: DOM: Security, defect, P2)

Description

[Daniel Holbert [:dholbert]]

(Spinning this off from bug 1984003 as a dedicated spot to discuss/land a particular fix strategy -- namely bug 1984003 comment 9 item (2).)

tl;dr:

• WebExtensions apparently rely on us using the triggeringPrincipal when we perform CORS checks for WebExtension-injected content.
• Bug 1496505 is where we originally made this use-case start working.
• ...but it wasn't obviously correct and broke other cases on the web; so bug 1970490 made us stop doing that and use the host document's origin for CORS checks instead (which seems to be generally correct).
• However: that broke this use-case in WebExtensions (which has at least one historical[1] and current[2] known-to-be-affected extension).
• ...and breaking extensions isn't great, and the old behavior arguably wasn't particularly problematic or dangerous specifically for WebExtension-injected-content.
• So: for now, let's go back to using the triggeringPrincipal for these checks, specificially if the triggeringPrincipal is for a WebExtension.

(Note that WebExtensions can also work around this themselves by shifting all of their injected content to web_accessible_resources as in bug 1984003 comment 5, but that isn't obviously the best thing to do, since I think that also lets web pages directly request the extension's content on their own, too, and that isn't great. Maybe at some point in the future we'll steer WebExtensions to do that or something similar, but for now we should let them keep working until we've got a concrete alternative recommendation.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: Bug 1985652: Use triggeringPrincipal rather than loadingPrincipal for CORS checks, if triggeringPrincipal is from an extension. r?emilio

This allows extensions to inject their own content into web pages, without that
injected content being automatically blocked due to failing CORS checks. See
the code-comment in the patch for more.

(Whether we should allow this is an open question; but we've been allowing it
for a while, and extensions currently depend on it, and it seems ~fine to let
extensions request their own resources; so let's preserve this use-case for now
as a special-case exception to bug 1970490's recent tightening of CORS checks
for more general web-content use-cases.)

Comment 2

[Daniel Holbert [:dholbert]]

[Tracking Requested - why for this release]: regression in 143, known to break at least one add-on (passff, discussed in bug 1984003).

Comment 4

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox143 (beta) and tracked for firefox144 (nightly). However, the bug still has low severity.

:freddy, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/433b77bc824f
https://hg.mozilla.org/integration/autoland/rev/25f4a2d3a659
Use triggeringPrincipal rather than loadingPrincipal for CORS checks, if triggeringPrincipal is from an extension. r=smaug,emilio,extension-reviewers,robwu

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/25f4a2d3a659

Comment 8

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:dholbert, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox143 to wontfix.

For more information, please visit BugBot documentation.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: Bug 1985652: Use triggeringPrincipal rather than loadingPrincipal for CORS checks, if triggeringPrincipal is from an extension. r?emilio

This allows extensions to access their own content from scripts that they
injected into web pages, without that requested content being automatically
blocked due to failing CORS checks (since the Origin of the request is
the web page).

We have an existing pref 'extensions.content_web_accessible.enabled' whose
'false' value is meant to allow MV2 extensions to access their own resources
from their content-scripts (even if those resources aren't web-exposed). A
recent CORS strictness patch broke this use-case; so this patch relaxes the
strictness, specifically for extensions and specifically when that pref has
the permissive 'false' value.

While we're at it, this patch extends the related xpcshell test cover the case
where the pref is in its default/permissive 'false' configuration (to test the
regression being addressed by this patch), and to test that MV3 is strict under
that configuration. This patch also clarifies the other relevant pref for CORS
principal-selection to avoid implying that it's relevant to WebExtensions
(since it's not anymore).

Original Revision: https://phabricator.services.mozilla.com/D262863

Comment 10

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Some extensions (passff at least) may stop working
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Steps in https://bugzilla.mozilla.org/show_bug.cgi?id=1984003#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: This is restoring a previously-shipping behavior. In particular: the regressor made us stricter for all content, which broke at least one extension; and this patch restores the previously-shipping behavior specifically for extensions (which have an implicit level of trust), in order to address the regression.
• String changes made/needed: None
• Is Android affected?: yes

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #8)

The patch landed in nightly and beta is affected.
:dholbert, is this bug important enough to require an uplift?

Yes.

• If yes, please nominate the patch for beta approval.

Done!

Comment 12

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (144.0a1/20250901162158) under Windows 11 and Ubuntu 24.04 LTS.

As per the STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1984003#c0 , accessing https://auth.wikimedia.org/enwiki/wiki/Special:UserLogin with PassFF installed will display a small P widget on the right-hand side of the login field, allowing interaction with the password manager.

I will check Beta as well once the uplift has been done.

Comment 13

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/86d1b3a13d34
https://hg.mozilla.org/releases/mozilla-beta/rev/a0e79275ce3b

Comment 14

[Alex Cornestean]

Verified as Fixed. Tested on the latest Beta (143.0b8/20250902115758 from https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=a0e79275ce3b97a330b889f451ae3544bc3bee27) under Windows 11 and Ubuntu 24.04 LTS.

As per the STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1984003#c0 , accessing https://auth.wikimedia.org/enwiki/wiki/Special:UserLogin with PassFF installed will display a small P widget on the right-hand side of the login field, allowing interaction with the password manager.

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: Bug 1985652: Use triggeringPrincipal rather than loadingPrincipal for CORS checks, if triggeringPrincipal is from an extension. r?emilio

This allows extensions to access their own content from scripts that they
injected into web pages, without that requested content being automatically
blocked due to failing CORS checks (since the Origin of the request is
the web page).

We have an existing pref 'extensions.content_web_accessible.enabled' whose
'false' value is meant to allow MV2 extensions to access their own resources
from their content-scripts (even if those resources aren't web-exposed). A
recent CORS strictness patch broke this use-case; so this patch relaxes the
strictness, specifically for extensions and specifically when that pref has
the permissive 'false' value.

While we're at it, this patch extends the related xpcshell test cover the case
where the pref is in its default/permissive 'false' configuration (to test the
regression being addressed by this patch), and to test that MV3 is strict under
that configuration. This patch also clarifies the other relevant pref for CORS
principal-selection to avoid implying that it's relevant to WebExtensions
(since it's not anymore).

Original Revision: https://phabricator.services.mozilla.com/D262863

Comment 16

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: If we uplift D263611 without also uplifting this revision, then we'll break some extnsions like passff. (i.e. this is essentially a required followup in order to let us uplift D263611; see that revision's uplift-request for its own justification.)
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Steps in https://bugzilla.mozilla.org/show_bug.cgi?id=1984003#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: This is restoring a previously-shipping behavior (the behavior that we're shipping on ESR140 currently), specifically for extensions, while letting the related patch's increased strictness remain in-place for web content.
• String changes made/needed: None
• Is Android affected?: yes

Comment 17

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: If we uplift D263611 without also uplifting this revision, then we'll break some extnsions like passff. (i.e. this is essentially a required followup in order to let us uplift D263611; see that revision's uplift-request for its own justification.)
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Steps in https://bugzilla.mozilla.org/show_bug.cgi?id=1984003#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: This is restoring a previously-shipping behavior (the behavior that we're shipping on ESR140 currently), specifically for extensions, while letting the related patch's increased strictness remain in-place for web content.
• String changes made/needed: None
• Is Android affected?: yes

Comment 18

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/ef9cc44911ab

Comment 19

[Alex Cornestean]

Verified as Fixed. Tested on the latest ESR (140.3.0esr/20250904033942 from https://treeherder.mozilla.org/jobs?repo=mozilla-esr140&revision=ef9cc44911abbed45a30d15ea47299567fd3408c) under Windows 11 and Ubuntu 24.04 LTS.

As per the STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1984003#c0 , accessing https://auth.wikimedia.org/enwiki/wiki/Special:UserLogin with PassFF installed will display a small P widget on the right-hand side of the login field, allowing interaction with the password manager.