更新
2023 年 3 月 23 日：我們已更新時間表，Chrome 117 版才會淘汰此 API。
2023 年 1 月 19 日：我們已更新時間表，Chrome 114 版才會淘汰此功能。
2022 年 8 月 12 日：我們已更新時間表，Chrome 109 才會淘汰此 API。
2022 年 2 月 10 日：更新的文章已發布於「私人網路存取：推出預檢功能」
2021 年 8 月 25 日：宣布更新時間表，並推出淘汰測試。
根據私人網路存取權規格，Chrome 將淘汰從非安全網站存取私人網路端點的功能。旨在保護使用者免於鎖定私人網路中的路由器和其他裝置的跨網站要求偽造 (CSRF) 攻擊。這些攻擊影響了數十萬名使用者，攻擊者將他們重新導向至惡意伺服器。
Chrome 將推出下列異動：
- 從 Chrome 94 版開始，封鎖來自不安全公開網站向私人網路的要求。
- 推出淘汰前測試版，並在 Chrome 中結束測試
- 可讓開發人員為所選來源要求延長期限，這在淘汰試用期間不會受到影響。
- 推出 Chrome 政策，讓受管理的 Chrome 部署作業永久略過淘汰。適用於 Chrome 92。
如果您需要更多時間，以便減輕淘汰註冊的淘汰試用期影響。
如果您具備使用者的管理控制項，則可以使用 Chrome 政策重新啟用這項功能。
如要減輕新限制的影響，請採用下列其中一種策略：
時間軸
- 2020 年 11 月：針對即將推出的異動來電提供意見。
- 2021 年 3 月：查看意見回饋和推廣活動後，宣布即將實施的異動。規格名稱已從 CORS-RFC1918 改為 Private Network Access。
- 2021 年 4 月：Chrome 90 穩定版推出，顯示淘汰警告。
- 2021 年 6 月：Chrome 92 版推出 Beta 版，禁止從不安全內容發出私人網路要求。開發人員提出意見，要求更多調整時間後，我們將淘汰作業延後至 Chrome 93，並搭配淘汰功能試用版。
- 2021 年 7 月：根據開發人員的進一步意見回饋，此淘汰項目和隨附的試用程序已延後到 Chrome 94 版。此外，私人網站也不再受到淘汰政策的影響。
- 2021 年 8 月：Chrome 94 推出 Beta 版。網頁開發人員可以開始申請淘汰前測試版。
- 2021 年 9 月：Chrome 94 穩定版推出。網頁開發人員應已註冊淘汰前測試計畫，並將試用權杖部署至正式版。
- 2022 年 12 月：發送來源試用問卷調查並收到意見回饋。淘汰期已延長至 Chrome 113。
- 2023 年 3 月：淘汰前測試版將延長至 Chrome 116，並設定在 Chrome 117 結束。權限型替代機制仍在開發階段，目標為 Chrome 114 的初始版本。
- 2023 年 5 月 (暫定)：Chrome 114 推出以權限為基礎的機制。網站可以使用這個值來退出淘汰試用計畫。
- 2023 年 9 月：推出 Chrome 117 至穩定版，並結束淘汰試用計畫。 Chrome 會封鎖來自公開、不安全內容的所有私人網路要求。
什麼是私人網路存取權
私人網路存取權 (之前稱為 CORS-RFC1918) 會限制網站向私人網路上伺服器傳送要求的功能。這項功能只允許來自安全環境的這類要求。規範也擴充了跨來源資源共享 (CORS) 通訊協定，讓網站在傳送任意要求前，必須先向私人網路上的伺服器明確要求授權。
私人網路要求是指要求的目標伺服器 IP 位址比要求啟動端擷取的 IP 位址更為私密。例如從公開網站 (https://example.com) 到私人網站 (http://router.local) 的請求，或是從私人網站到本機的請求。
如要進一步瞭解，請參閱「私人網路的 CORS (RFC1918)：歡迎提供意見回饋」。
淘汰試用計畫
淘汰功能試驗 (舊稱為反向來源試驗) 是一種來源試驗，可用於協助淘汰網路功能。淘汰試驗可讓 Chrome 淘汰特定網頁功能，並防止網站建立新的依附性，同時讓目前依附的網站有額外時間遷移。
在淘汰試用期間，根據預設，所有網站都無法使用已淘汰的功能。如果開發人員仍需要使用受影響的功能，就必須註冊淘汰試用方案，並取得指定網站來源的符記，然後修改網站，以便在 HTTP 標頭或中繼標記中提供這些符記 (本案例除外)。如果網站提供與來源相符的有效權杖，Chrome 會允許使用已淘汰的功能一段時間。
如需更多資訊，請參閱「Chrome 來源試用功能的入門指南」和「來源試用功能的網頁開發人員指南」瞭解操作說明。
Chrome 的異動內容
Chrome 94
自 Chrome 94 起，公開的不安全內容 (廣義來說，就是未透過 HTTPS 或私人 IP 位址提供的網站) 將無法向私人網路傳送要求。我們先前已規劃 Chrome 92 版的這項功能，因此淘汰訊息可能仍會提到先前的里程碑。
這項淘汰作業會搭配淘汰試用計畫，讓網站使用淘汰功能的網頁開發人員在註冊符記前，可以繼續使用該功能，直到 Chrome 116 版為止。請參閱下方的操作說明，瞭解如何在網站上註冊並啟用試用方案。
您可以使用一組 Chrome 政策，無限期或在特定來源中永久停用淘汰作業。這樣一來，受管理的 Chrome 安裝作業 (例如公司設定中的安裝作業) 就不會中斷。
Chrome 117
淘汰試用期已結束。所有網站都必須從已淘汰的功能遷移，或將使用者的政策設為繼續啟用該功能。
建議的開發人員動作
受影響的網站在等待適當修正方案部署前，最有可能採取的第一步驟是註冊淘汰前測試或使用政策。接著，建議的行動方式會因各受影響網站的情況而異。
註冊淘汰前測試版
- 按一下「註冊」，針對非安全內容來源試用中的私人網路存取，取得參與來源的試用權杖。
- 將特定來源的
Origin-Trial: $token新增至回應標頭。只有在產生的文件使用已淘汰的功能時，才需要在主要資源和導覽回應中設定這個回應標頭。將這個標頭附加至子資源回應是無用的 (但不會造成傷害)。
由於必須先啟用或停用這項試用功能，文件才能提出任何要求，因此無法透過 <meta> 代碼啟用這項功能。只有在發出子資源要求後，系統才會從回應主體剖析這類標記。這對無法控制回應標頭的網站 (例如由第三方提供的 github.io 靜態網站) 來說，是一項挑戰。
詳情請參閱網頁開發人員的來源測試指南。
啟用政策
如果您對使用者有管理控制權，可以使用下列任一政策重新啟用已淘汰的功能：
如要進一步瞭解如何管理使用者的政策，請參閱這篇說明中心文章。
存取 localhost
如果您的網站需要向 localhost 發出要求，您只需要將網站升級為 HTTPS。
即使是從安全內容發出的請求，如果指定 http://localhost (或 http://127.*.*.*、http://[::1])，也不會遭到混合內容封鎖。
請注意，WebKit 引擎和以此為基礎的瀏覽器 (特別是 Safari) 在此違反 W3C 混合內容規格，且禁止將這些要求視為混合內容。這類瀏覽器也不會實作私人網路存取功能，因此網站可能會將使用這類瀏覽器的用戶端重新導向至網站的純文字 HTTP 版本，這類瀏覽器仍可向 localhost 提出要求。
存取私人 IP 位址
如果您的網站需要向私人 IP 位址的目標伺服器發出要求，那麼只要將發起網站升級為 HTTPS 就無法運作。複合型內容會防止安全內容區塊透過純文字 HTTP 提出要求，因此新安全網站仍會發現自己無法提出要求。解決這個問題的方法有幾種：
- 將兩端升級為 HTTPS。
- 使用 WebTransport 安全連線至目標伺服器。
- 反轉嵌入關係。
將兩者皆升級至 HTTPS
這個解決方案需要您控管使用者的 DNS 解析，例如：可能在內部網路環境下，或使用者是否從您控管的 DHCP 伺服器取得其名稱伺服器位址。您也必須擁有公開網域名稱。
透過 HTTPS 提供私人網站的主要問題是，公開金鑰基礎架構憑證授權單位 (PKI CA) 只會為具有公開網域名稱的網站提供 TLS 憑證。解決方法如下：
- 註冊公開網域名稱 (例如
intranet.example)，並發布 DNS 記錄，將該網域名稱指向您選擇的公開伺服器。 - 取得
intranet.example的 TLS 憑證。 - 在私人網路內部，設定 DNS 以將
intranet.example解析為目標伺服器的私人 IP 位址。 - 將私人伺服器設為使用
intranet.example的 TLS 憑證。這可讓使用者透過https://intranet.example存取私人伺服器。
接著，您可以將發出要求的網站升級為 HTTPS，並繼續如先前一樣提出要求。
這個解決方案可因應未來需求，並降低您對網路的信任程度，擴大在私人網路中使用端對端加密的範圍。
WebTransport
這項解決方案不需要控制使用者的 DNS 解析。但這項功能需要目標伺服器執行最小 WebTransport 伺服器 (經過一些修改的 HTTP/3 伺服器)。
您可以使用 WebTransport 及其憑證綁定機制，略過缺少由信任 CA 簽署的有效 TLS 憑證。這樣就可以為可能擁有自行簽署憑證之私人裝置建立安全連線。WebTransport 連線可進行雙向資料傳輸，但無法擷取要求。您可以將這個方法與 Service Worker 結合，從網頁應用程式的角度，透過連線透明的 Proxy HTTP 要求。在伺服器端，對應的轉譯層可將 WebTransport 訊息轉換為 HTTP 要求。
我們瞭解這項工作相當繁重，但這應該比在 WebRTC 上建構要簡單得多；我們也希望能將部分必要的投資實作為可重複使用的程式庫。我們也認為，考量到平台會隨著時間推移，以更強烈的方式鼓勵使用 HTTPS，因此不安全的內容可能會失去越來越多的網路平台功能存取權，因此這項做法特別值得。無論是否使用私人網路存取權，這都可能是明智的投資。
我們預計在 Chrome 96 中推出 WebTransport over HTTP/3 (已開始來源測試)，並提供緩解措施，以防範金鑰共用和其他不合標準的安全做法，包括：
- 綁定憑證的到期時間較短。
- 一種瀏覽器專屬機制，用於撤銷遭到濫用的特定金鑰。
在 WebTransport 完全推出後，我們至少會推出兩個里程碑，才會發布安全內容限制。如有需要，我們會延長淘汰試用計畫。
反向嵌入
這個解決方案不需要對網路進行任何管理控制，且可在目標伺服器效能不足以執行 HTTPS 時使用。
從公開網頁應用程式擷取私人子資源，可以從私人伺服器提供應用程式的架構，然後由私人伺服器 (例如 CDN) 擷取所有子資源 (例如指令碼或圖片)。產生的網頁應用程式可向私人伺服器提出要求，因為這些要求屬於相同來源。甚至可以向其他私人 IP (但不是 localhost) 伺服器提出要求，但這可能會在長期內有所變動。
只要在私人伺服器上託管骨架，您就能將新資源推送至公開伺服器，藉此更新網頁應用程式，就像更新公開網頁應用程式一樣。另一方面，產生的網頁應用程式並非安全的內容，因此無法存取網頁的部分強大功能。
未來計畫
將私人網路要求限制在安全的內容中，只是啟動私人網路存取權的第一步。Chrome 會在未來幾個月內實作規格中的其他部分。敬請密切關注最新消息！
限制私人網站的 localhost 存取權
Chrome 94 版的異動只會影響存取私人 IP 位址或 localhost 的「公開」網站。私人網路存取權規格也將從私人網站傳送至 localhost 的要求歸類為有問題。Chrome 最終也會淘汰這些功能。不過，這會帶來一些稍有不同的挑戰，因為許多私人網站都沒有網域名稱，因此使用淘汰測試權杖會變得複雜。
CORS 預檢要求
私人網路存取權的第二部分，是使用 CORS 預先檢查要求，針對從安全內容啟動的私人網路要求進行篩選。這項功能的概念是，即使要求是從安全內容啟動，系統也會要求目標伺服器向發起端提供明確授權。只有在授權成功時，系統才會傳送要求。
簡而言之，CORS 預檢要求是一種 HTTP OPTIONS 要求，會攜帶一些 Access-Control-Request-* 標頭，指出後續要求的性質。接著，伺服器可以決定是否要授予精細存取權，方法是使用 Access-Control-Allow-* 標頭回應 200 OK。
如需進一步瞭解這項功能，請參閱規格。
限制導覽擷取
Chrome 會淘汰並最終封鎖私人網路的子資源要求。這不會影響導向私人網路的動作，後者也可用於 CSRF 攻擊。
私人網路存取規格不會區分這兩種擷取作業，因此最終都會受到相同的限制。
封面相片：由 Markus Spiske 提供，位於 Unsplash 上