1984359 - Wrong origin of Local Network Access warning from addons running against a self-hosted service

Status: RESOLVED WORKSFORME

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

Description

[Nicolas B. Pierron [:nbp]]

Problem

Every time there is a login form of login.example.com, I get a warning against login.example.com making access to apps and services on devices connected to my local network.

Expectation

The warning should either not appear, or report the addon as being the source of the connection.

Correlation

Everytime I get the drop-down from the bitwarden addon, I can see the connections being made to the self-hosted remote.vpn.domain.name in the network panel of the devtools, while at the same time having a drop-down warning.

Note, the connection are coming through successfully even if blocked.

Setup

Today I have the following setup:

I have a tailscale connection under the domain.name domain.

• One computer named remote (100.64.0.17) which host vaultwarden behind nginx, and uses let's encrypt with DNS challenges to provide HTTPS connections.
• One computer named client (100.64.0.11) uses firefox with the bitwarden addon.

The bitwarden addon is configured to use the remote.vpn.domain.name computer.

Comment 1

[Nicolas B. Pierron [:nbp]]

Attachment: inject-fecth-localhost.zip

I was able to reproduce the issue using the attached addon, and modifying my /etc/hosts with an extra entry to change.me (matching the TARGET_URL in injected.js) which resolve to a valid local network address which serve some content.

Comment 2

[Rob Wu [:robwu]]

(In reply to Nicolas B. Pierron [:nbp] from comment #1)

Created attachment 9508501 [details]
inject-fecth-localhost.zip

I was able to reproduce the issue using the attached addon, and modifying my /etc/hosts with an extra entry to change.me (matching the TARGET_URL in injected.js) which resolve to a valid local network address which serve some content.

In this test case, the extension intentionally executes code in the context of the web page that calls fetch(). This is indistinguishable from other code from the web page itself, and therefore runs with web page privileges, not extension privileges.

Are you sure that your test case is comparable to Bitwarden's implementation? That would surprise me, because a web page's execution environment should be considered untrusted from the extension's point of view.

Everytime I get the drop-down from the bitwarden addon, I can see the connections being made to the self-hosted remote.vpn.domain.name in the network panel of the devtools, while at the same time having a drop-down warning.

Which devtools panel are you looking at? The tab's?
What is the call stack?
Is the code running in the page's context or the content script's context?
To debug content scripts, you first need to opt in to see its sources, as documented at https://extensionworkshop.com/documentation/develop/debugging/#debugging-content-scripts

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Rob Wu [:robwu] from comment #2)

(In reply to Nicolas B. Pierron [:nbp] from comment #1)
Are you sure that your test case is comparable to Bitwarden's implementation? That would surprise me, because a web page's execution environment should be considered untrusted from the extension's point of view.

I am not sure that BitWarden is implemented the same way.
I would guess not as the network panel from the devtools show the resource being fetched, despite having blocked it.

Everytime I get the drop-down from the bitwarden addon, I can see the connections being made to the self-hosted remote.vpn.domain.name in the network panel of the devtools, while at the same time having a drop-down warning.

Which devtools panel are you looking at? The tab's?

The network panel, from the devtools opened with Ctrl+Shift+I shortcut.

What is the call stack?

Looking at the network panel, I do not see any stack, even after turning on debugging-content-scripts.
Yet the initiator is menu-list.js:1356 , which does not belong to any loaded script.
I can see some extension scripts being loaded temporarily, including a page menu.html which disappear as soon as the page looses focus.

I do not know how to freeze the page to find out about the content script / iframe content.

Is the code running in the page's context or the content script's context?

I do not know how to test that.

Given that a new iframe is added and remove, I will suppose that this is a different context.

If you need more information, I can help you investigate the behavior over Zoom.

Comment 4

[Sunil Mayya]

If the request is coming from extension, it should be given access to the local host resources without prompting. Chrome is implementing it in a similar way.
I need to add check for this in the necko code to allow requests coming from extensions to skip LNA checks.

Comment 5

[Nicolas B. Pierron [:nbp]]

Nightly 146.0a1 (2025-10-31) does not reproduce the issue using the setup described in comment 0.

Comment 6

[Nicolas B. Pierron [:nbp]]

Experiencing the process described in comment 0, yielded a popup which mention the addon name.
Sounds like this is properly fixed for the BitWarden addon.