本頁面由 Cloud Translation API 翻譯而成。

區域網路存取權的新權限提示

Chris Thompson

發布日期：2025 年 6 月 9 日

Chrome 會根據區域網路存取規範草案，為連線至使用者區域網路的網站新增權限提示。目的是保護使用者免於遭受跨網站要求偽造 (CSRF) 攻擊，鎖定私人網路上的路由器和其他裝置，並減少網站使用這些要求來建立使用者本機網路指紋的能力。

為瞭解這項異動對網頁生態系統的影響，Chrome 團隊希望開發人員提供意見回饋，這些開發人員會建構網頁應用程式，而這些應用程式需要連線至使用者的本機網路或在使用者電腦上執行的本機軟體。從 Chrome 138 開始，您可以前往 chrome://flags/#local-network-access-check 並將標記設為「Enabled (Blocking)」，選擇啟用這些新限制。

什麼是區域網路存取權？

本機網路存取權會限制網站向使用者本機網路上的伺服器 (包括在使用者電腦上本機執行的伺服器) 傳送要求的功能，要求使用者授予網站權限，才能提出這類要求。要求這項權限的功能僅限於安全情境。

提示訊息，內容為「尋找區域網路上的任何裝置並連線」。 — Chrome 的區域網路存取權提示範例。

許多其他平台 (例如 Android、iOS 和 MacOS) 都有本機網路存取權。舉例來說，你可能在設定新的 Google TV 和 Chromecast 裝置時，將這項權限授予 Google Home 應用程式，以便存取本機網路。

哪些類型的要求會受到影響？

在區域網路存取權的第一個里程碑中，我們將「區域網路要求」視為任何從公開網路區域網路或迴圈目的地傳送的要求。

本機網路是指任何可解析為 IPv4 中 RFC1918 第 3 節所定義私人位址空間的目的地 (例如 192.168.0.0/16)、IPv4 對應的 IPv6 位址 (其中對應的 IPv4 位址本身為私人)，或是 ::1/128、2000::/3 和 ff00::/8 子網路以外的 IPv6 位址。

Loopback 是指任何會解析至 IPv4 的 RFC1122 3.2.1.3 節定義的「loopback」空間 (127.0.0.0/8)、IPv4 的 RFC3927 3 節定義的「link-local」空間 (169.254.0.0/16)、IPv6 的 RFC4193 3 節定義的「Unique Local Address」前置字 (fcc00::/7)，或是 IPv6 的 RFC4291 2.5.6 節定義的「link-local」前置字 (fe80::/10) 的目的地。

公共網路是指任何其他目的地。

由於區域網路存取權限僅限於安全內容，且區域網路裝置很難遷移至 HTTPS，因此如果 Chrome 知道要求會在解析目的地之前傳送至區域網路，則權限控管的區域網路要求現在將免於混合內容檢查。在下列情況下，Chrome 會知道要求會傳送至本機網路：

請求主機名稱為私人 IP 文字常值 (例如 192.168.0.1)。
要求主機名稱是 .local 網域。
fetch() 呼叫會加上 targetAddressSpace: "local". 選項註解

// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");

// Example 2: `.local` domain is exempt from mixed content.
fetch("http://router.local/ping");

// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");

// Example 4: Adding the `targetAddressSpace` option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
  targetAddressSpace: "local",
});

Chrome 的異動內容

Chrome 138

我們已準備好初始版本的區域網路存取權，讓您在 Chrome 138 中進行自願測試。使用者可以將 chrome://flags#local-network-access-check 設為「Enabled (Blocking)」，啟用新的權限提示訊息。這項功能可針對使用 JavaScript fetch() API、子資源載入和子框架導覽所啟動的請求，觸發「區域網路存取權」權限提示。

如要觸發不同形式的本機網路要求，請前往 https://local-network-access-testing.glitch.me/ 查看示範網站。

已知問題和限制

新的權限提示目前僅在 Chrome 電腦版上實作。我們正在積極將這項功能移植到 Android 版 Chrome。(已在 crbug.com/400455013 中追蹤)。
WebSockets (crbug.com/421156866)、WebTransport (crbug.com/421216834) 和 WebRTC (crbug.com/421223919) 連線至本機網路的權限尚未受到 LNA 權限限制。
目前，服務工作者發出的區域網路要求，必須先取得服務工作者的來源，才能獲得區域網路存取權。
- 如果您的應用程式透過服務工作者提出區域網路要求，您目前需要從應用程式中個別觸發區域網路要求，才能觸發權限提示。(我們正在研究如何讓工作者在有可用的有效文件時觸發權限提示，請參閱 crbug.com/404887282)。

Chrome 139 以上版本

我們會盡快推出區域網路存取權。我們瞭解部分網站可能需要額外時間才能更新區域網路存取權註解，因此會新增來源測試功能，讓網站暫時選擇不採用安全內容限制，然後我們會預設提供區域網路存取權。這應該可為開發人員提供更明確的遷移路徑，尤其是如果您需要透過 HTTP 存取區域網路資源 (如果在尚未支援區域網路存取混合內容豁免條款的瀏覽器中，透過 HTTPS 頁面提出要求，這些要求就會遭到封鎖，視為混合內容)。

我們也會新增 Chrome 企業政策，用於控制哪些網站可以和不可以提出本機網路要求 (預先授予或預先拒絕這些網站的權限)。這樣一來，受管理的 Chrome 安裝作業 (例如企業設定中的安裝作業) 就不會在已知的預期用途下顯示警告，或進一步鎖定並防止網站要求權限。

我們計劃繼續將區域網路存取權授權與可向區域網路傳送要求的不同功能整合。舉例來說，我們預計很快就會為 WebSockets、WebTransport 和 WebRTC 連線提供本機網路存取權。

隨著 Chrome 的本機網路存取功能推出，我們會提供更多資訊。

希望提供意見

先前針對私人網路存取權開發作業提供的意見非常寶貴，協助我們制定新的區域網路存取權權限方法。再次感謝所有多年來的參與者。

如果您是開發人員或網站使用者，且網站需要連線至使用者的本機網路或在使用者的電腦上執行的本機軟體，Chrome 團隊很想瞭解您的意見回饋和用途。您可以採取以下兩種做法：

前往 chrome://flags#local-network-access-check，將標記設為「已啟用 (封鎖)」，然後查看網站是否正確觸發新的權限提示 (並在您授予權限後正常運作)。
如果您遇到任何問題或有任何意見回饋，請在 Chromium Issue Tracker 或 LNA 說明 GitHub 存放區中提出問題。Chrome 很樂意聽取你的意見。