Chrome 正在計劃禁止從非安全網站發起的專用網絡請求，目的是保護用戶免受針對專用網絡上的路由器和其他設備的跨站點請求偽造 (CSRF) 攻擊：

從 Chrome 94 開始阻止來自不安全公共網站的私有網絡請求。在 Chrome 101 中結束的棄用試驗。在 Chrome 92 中引入一些 Chrome 策略，允許托管的 Chrome 部署永久繞過棄用。

啥是專用網絡？

在互聯網的地址架構中，專用網絡是指遵守 RFC 1918（IPV4）和 RFC 4193（IPV6）規范，使用專用 IP 地址空間的網絡。私有 IP 無法直接連接互聯網，需要使用網絡地址轉換（Network Address Translator，NAT）或者代理服務器（proxy server）來實現。

(相關資料圖)

一般，我們在企業里搭建的局域網、家庭網絡里的局域網、你本地的 localhost ，都屬于專用網絡。

專用網絡訪問規范

專用網絡訪問規范（以前稱為 CORS-RFC1918）會限制網站向專用網絡上的服務器發送請求的能力。它只允許來自安全上下文（HTTPS）的此類請求。該規范還擴展了跨域資源共享 (CORS) 協議，因此網站現在必須要經過專用網絡上的服務器授權會才能發送請求。

私有網絡請求是其目標服務器的 IP 地址比獲取請求發起者的 IP 地址更私有的請求。例如，從公共網站 ( https://example.com) 到私有網站 (http://router.local) 的請求，或從私有網站到 localhost 的請求。我們在開發過程中，這幾種情況實際上是比較常見的，所以需要開發者提前試用并作出應對。

訪問 localhost

如果你的網站需要向 localhost 發出請求，那么你只需要將你的網站升級到 HTTPS?；旌蟽热莶粫柚挂?http://localhost（或 http://127.*.*.*、http://[::1]）為目標的請求，即使是從安全上下文發出的。

請注意，這里有個坑，WebKit 引擎和基于它的瀏覽器（比如 Safari）這里并沒有遵循 W3C 混合內容規范，上面這些請求會作為混合內容并禁止訪問。它們也沒有實現專用網絡訪問，因此網站如果使用此類瀏覽器的客戶端，需要試用 HTTP 協議，此類瀏覽器仍允許向 localhost 發出請求。

訪問私有 IP

如果你的網站需要向私有 IP 地址上的目標服務器發出請求，那么簡單地將發起方網站升級到 HTTPS是行不通的?；旌蟽热輹柚拱踩舷挛耐ㄟ^明文 HTTP 發出請求，因此新獲得安全保護的網站仍會發現自己無法發出請求。有幾種方法可以解決這個問題：

將兩端都升級為HTTPS

這個方案難度有點大，因為 HTTPS 只會面向公共域名辦法，你需要先給你的私有 IP 注冊一個公共域名，然后配置 DNS 解析把公共域名指向這個私有 IP，最后再給域名配置 TLS 證書。

使用 WebTransport

這個方案不需要自己控制 DNS 解析，你需要在私有網絡上自己搭建一個 WebTransport 服務器。WebTransport 是 WebRTC 體系下的一套瀏覽器API ，提供低延遲，client 和 server之間雙向通信的能力。

WebTransport 提供基于 QUIC 和 HTTP3 實現的API ，自動獲得 QUIC 和 HTTP3本身的特性，比如應用層的擁塞，避免隊頭阻塞。雙向通信的能力，多個傳輸通道復用一個連接的能力，能夠很好的替代 WebSocket。提供發送/接受不可靠 UDP 的能力，這個是瀏覽器一直欠缺的能力。

重要的是，通過使用 WebTransport 的證書鎖定機制，你可以繞過缺少由受信任 CA 簽署的有效 TLS 證書的問題。

反向嵌入。

網站的框架可以從私有服務器獲取，然后從公共服務器(如CDN)獲取它的所有子資源(如 script 或 image)。這樣生成的網站可以向私有服務器發出請求，因為這些請求是同源的，它甚至可以向其他使用私有 ip 發出請求。

這個方案可以臨時用，官網所可能以后對這種情況也會有所限制。

CORS 預檢請求的變化

CORS 預檢請求是一個 HTTP OPTIONS 請求，它帶有一些 Access-Control-Request-* 標頭，表明后續請求的性質，例如是否允許跨域訪問。專用網絡訪問規范的第二部分是使用 CORS 預檢請求來控制從安全上下文發起的專用網絡請求。即使請求是從安全上下文發起的，目標服務器也會被要求向發起者提供明確的授權，只有在授權成功時才會發送請求。