發布日期：2025 年 6 月 9 日
Chrome 將為連線至使用者區域網路的網站新增權限提示，這是區域網路存取規格的一部分。目的是保護使用者免於跨網站要求偽造 (CSRF) 攻擊，這類攻擊會鎖定私人網路上的路由器和其他裝置，並減少網站使用這些要求來建立使用者本機網路指紋的能力。
為瞭解這項異動對網路生態系統的影響，Chrome 團隊正在徵求開發人員的意見回饋。如果您開發的網路應用程式會連線至使用者的本機網路，或連線至使用者電腦上執行的本機軟體，歡迎提供意見。從 Chrome 138 開始，您可以前往 chrome://flags/#local-network-access-check，將標記設為「已啟用 (封鎖)」，選擇啟用這些新限制。
什麼是區域網路存取權？
區域網路存取權會限制網站向使用者區域網路上的伺服器傳送要求 (包括在使用者電腦上本機執行的伺服器)，因此網站必須先取得使用者授權，才能傳送這類要求。只有安全情境才能要求這項權限。
許多其他平台 (例如 Android、iOS 和 MacOS) 都有本機網路存取權。舉例來說，設定新的 Google TV 和 Chromecast 裝置時，你可能已授予 Google Home 應用程式存取區域網路的權限。
哪些類型的要求會受到影響？
在區域網路存取權的第一個里程碑，我們將「區域網路要求」視為從公用網路到區域網路或迴路目的地的任何要求。
本機網路是指任何可解析為 RFC1918 第 3 節中定義的私人位址空間 (例如 192.168.0.0/16)、對應 IPv4 的 IPv6 位址 (其中對應的 IPv4 位址本身為私有位址)，或是 ::1/128、2000::/3 和 ff00::/8 子網路以外的 IPv6 位址。
迴路是指解析為「迴路」空間 (127.0.0.0/8) 的任何目的地，如 RFC1122 的 IPv4 3.2.1.3 節所定義；解析為「連結本機」空間 (169.254.0.0/16) 的任何目的地，如 RFC3927 的 IPv4 所定義；解析為「唯一本機位址」前置字元 (fcc00::/7) 的任何目的地，如 RFC4193 的 IPv6 3 節所定義；或解析為「連結本機」前置字元 (fe80::/10) 的任何目的地，如 RFC4291 的 IPv6 2.5.6 節所定義。
如需 IP 位址對應位址空間的完整資訊，請參閱區域網路存取規格中的表格。
公用網路是指任何其他目的地。
由於區域網路存取權僅限於安全環境，且將區域網路裝置遷移至 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 設為「已啟用 (封鎖)」，啟用新的權限提示。這項功能支援為使用 JavaScript fetch() API、子資源載入和子框架導覽啟動的要求，觸發區域網路存取權許可提示。
如要觸發不同形式的本機網路要求，請前往https://lna-testing.notyetsecure.com/ 查看示範網站。
已知問題和限制
- 目前，連往本機網路的 WebSocket (crbug.com/421156866)、WebTransport (crbug.com/421216834) 和 WebRTC (crbug.com/421223919) 連線，尚未受到 LNA 權限控管。
- Service Worker 和 Shared Worker 的區域網路要求，必須先授予 Worker 來源區域網路存取權。
- 如果應用程式從 Service Worker 發出區域網路要求，您需要從應用程式個別觸發區域網路要求，才能觸發權限提示。(我們正在開發相關功能，讓工作人員在有可用的有效文件時，觸發權限提示 - 請參閱 crbug.com/404887282)。
Chrome 139 以上版本
我們希望盡快推出區域網路存取權功能。我們瞭解部分網站可能需要額外時間，才能更新區域網路存取權註解，因此在預設啟用區域網路存取權之前，我們會新增 Origin Trial，讓網站暫時停用安全環境規定。這項做法可為開發人員提供更明確的遷移路徑，特別是如果您透過 HTTP 存取區域網路資源 (如果從不支援區域網路存取混合內容豁免的瀏覽器，透過 HTTPS 網頁要求這些資源，系統會將其視為混合內容而封鎖)。
我們也會新增 Chrome 企業政策，控管哪些網站可以提出本機網路要求，哪些網站則不行 (預先授予或拒絕這些網站的權限)。這樣一來，受管理 Chrome 安裝 (例如企業環境中的安裝) 就能避免針對已知預期用途顯示警告，或進一步鎖定並禁止網站要求這項權限。
我們計畫繼續將「區域網路存取權」權限整合至可向區域網路傳送要求的不同功能。舉例來說，我們計畫在不久後推出適用於 WebSocket、WebTransport 和 WebRTC 連線的區域網路存取權。
我們會在 Chrome 完整推出「本機網路存取權」功能前，分享更多資訊。
歡迎提供意見
先前您對私人網路存取權開發作業提供的意見回饋非常寶貴，有助我們採用新的區域網路存取權許可方法。再次感謝多年來參與這項計畫的每個人。
如果您開發或使用網站時，需要連線至使用者的本機網路，或使用者電腦上執行的本機軟體，Chrome 團隊很想聽取您的意見和瞭解您的用途。你可以採取以下兩種做法：
- 前往
chrome://flags#local-network-access-check，將旗標設為「Enabled (Blocking)」，然後查看網站是否正確觸發新的權限提示 (並在您授予權限後正常運作)。 - 如有任何問題或意見，請在 Chromium 問題追蹤器或 LNA 規格 GitHub 存放區中提出。歡迎與 Chrome 分享你的意見。