更新
2023 年 3 月 23 日：时间表已更新，弃用到 Chrome 117 才生效。
2023 年 1 月 19 日：时间表已更新，弃用到 Chrome 114 才不会弃用。
2022 年 8 月 12 日：时间表已更新，弃用到 Chrome 109 才不会弃用。
2022 年 2 月 10 日：专用网络访问：介绍预检一文发布了更新的文章
2021 年 8 月 25 日：更新了时间表公告，并推出了弃用试用。
按照专用网络访问规范，Chrome 将不再支持从非安全网站访问专用网络端点。这样做的目的是保护用户免受针对专用网络上的路由器和其他设备的跨站请求伪造 (CSRF) 攻击。这些攻击影响了数十万用户，使攻击者能够将其重定向到恶意服务器。
Chrome 将引入以下变更：
- 从 Chrome 94 开始，禁止不安全的公开网站向专用网络发送请求。
- 推出将在 Chrome 中结束的弃用试用
- 它将允许开发者为所选源站申请延期，在弃用试用期间不会受到影响。
- 推出了 Chrome 政策，该政策将允许受管理的 Chrome 部署永久绕过弃用。适用于 Chrome 92。
如果您需要更多时间来减轻弃用的影响，请注册弃用试用。
如果您对用户拥有管理控制权，则可以使用 Chrome 政策重新启用该功能。
为了减轻新限制的影响，请使用以下策略之一：
时间轴
- 2020 年 11 月：欢迎您就即将发生的变化提供反馈。
- 2021 年 3 月：在审核反馈并主动联系后，我们宣布即将发生的变化。该规范已从 CORS-RFC1918 重命名为专用网络访问。
- 2021 年 4 月：Chrome 90 发布到稳定版，并显示弃用警告。
- 2021 年 6 月：Chrome 92 发布 Beta 版，禁止发出来自不安全上下文的专用网络请求。在收到开发者的反馈，要求他们有更多时间进行调整后，我们会将弃用日期推迟到 Chrome 93，同时附带弃用试用。
- 2021 年 7 月：在获得开发者的进一步反馈后，Chrome 94 的弃用时间以及附带的试用版的功能已推迟到 Chrome 94。此外，专用网站不再受到弃用的影响。
- 2021 年 8 月：Chrome 94 发布 Beta 版。Web 开发者可以开始注册试用弃用版本。
- 2021 年 9 月：Chrome 94 发布到稳定版。Web 开发者应该已注册弃用试用版并将试用令牌部署到生产环境中。
- 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) 的请求，或从私有网站发送到 localhost 的请求。
有关详情，请参阅 Feedback Want: CORS for Private Networks (RFC1918)。
什么是弃用试用
弃用试用（以前称为“反向源试用”）是一种源试用，用于简化 Web 功能的弃用。通过弃用试用，Chrome 可以弃用某些 Web 功能并防止网站对这些功能形成新的依赖关系，同时为当前依赖的网站留出额外的时间来迁离这些功能。
在弃用试用期间，默认情况下，所有网站都无法使用已弃用的功能。如果开发者仍需要使用受影响的功能，则必须注册参与弃用试用并获得指定网站源的令牌，然后修改其网站，以便在 HTTP 标头或元标记中提供这些令牌（在这种情况下除外）。如果网站提供与其来源匹配的有效令牌，Chrome 将允许在限定时间内使用已弃用的功能。
如需了解详情，请参阅 Chrome 源试用使用入门和有关源试用的 Web 开发者指南，获取相关说明。
Chrome 中发生的变化
Chrome 94
从 Chrome 94 开始，公共非安全上下文（一般来说，不是通过 HTTPS 或专用 IP 地址传送的网站）将禁止向专用网络发出请求。之前，我们计划在 Chrome 92 中执行此操作，因此弃用消息可能仍会提及早期的里程碑。
弃用后，同时也会进行弃用试用，让自己网站的 Web 开发者可以通过注册令牌在 Chrome 116 之前继续使用已弃用的功能。如需了解如何在您的网站上注册和启用试用，请参阅下文。
可利用一组 Chrome 政策来完全或针对特定源无限期停用弃用。这样可允许受管理的 Chrome 安装（例如企业设置中的 Chrome 安装），以免出现服务中断。
Chrome 117
弃用试用结束。所有网站都必须从已弃用的功能中迁出，或将其用户的政策配置为继续启用该功能。
建议的开发者操作
对于受影响的网站，首先要做的就是考虑花上一些时间来部署适当的修复：注册弃用试用或使用政策。然后，建议采取的措施会因每个受影响网站的情况而异。
注册弃用试用
- 点击注册以进行来自非安全上下文源试用的专用网络访问，为参与来源获取试用令牌。
- 将特定于源的
Origin-Trial: $token添加到响应标头中。仅当生成的文档使用已弃用的功能时，才需要在主要资源和导航响应中设置此响应标头。将此标头附加到子资源响应没有用（尽管没有坏处）。
由于必须先启用或停用此试验，然后才能允许文档发出任何请求，因此无法通过 <meta> 标记启用此试验。只有在可能已发出子资源请求后，系统才会从响应正文解析此类标记。这给无法控制响应标头的网站（例如由第三方提供的 github.io 静态网站）带来了挑战。
如需了解详情，请参阅针对源试用的 Web 开发者指南。
启用政策
如果您对用户拥有管理控制权，则可以使用以下任一政策重新启用已弃用的功能：
如需详细了解如何为用户管理政策，请参阅这篇帮助中心文章。
访问 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 结合使用，从 Web 应用的角度通过连接以透明方式代理 HTTP 请求。在服务器端，相应的翻译层可以将 WebTransport 消息转换为 HTTP 请求。
我们承认，这需要完成大量工作，但这应该比基于 WebRTC 构建容易得多；我们还希望，一些必要的投资能以可重复使用的库的形式实现。同时，我们认为非安全上下文可能会失去对越来越多的网络平台功能的访问权限，这一点非常值得，因为平台会逐渐以更强有力的方式鼓励 HTTPS 使用。无论专用网络访问通道如何，这仍然是明智的投资。
我们预计 WebTransport over HTTP/3 将在 Chrome 96 中推出（它已经开始了源试用），并提供缓解措施以防止密钥共享和其他不合标准的安全做法，包括：
- 固定证书的较短到期时间。
- 一种特定于浏览器的机制，用于撤消某些可能遭到滥用的密钥。
在 WebTransport 全面推出后，至少有两个里程碑，我们才会实施安全上下文限制。如果需要，弃用试用将延长。
反向嵌入
此解决方案不需要对网络的任何管理控制，并且可以在目标服务器功能不足以运行 HTTPS 时使用。
您可以从公共服务器（例如 CDN）提取其所有子资源（例如脚本或图片），而不是从公共 Web 应用提取私有子资源。然后，生成的 Web 应用可以向专用服务器发出请求，因为这些请求被视为同源。它甚至可以向使用专用 IP（而非 localhost）的其他服务器发出请求，但长期可能会发生变化。
通过在专用服务器上仅托管框架，您可以通过将新资源推送到公共服务器来更新 Web 应用，就像更新公共 Web 应用一样。另一方面，生成的 Web 应用不安全，因此它无法访问某些更强大的 Web 功能。
未来计划
限制专用网络请求仅在安全上下文中发出，只是启动专用网络访问的第一步。Chrome 正努力在未来几个月内实施该规范的其余部分。敬请关注最新动态！
限制从私有网站进行 localhost 访问
Chrome 94 中的变更仅影响访问专用 IP 地址或 localhost 的公共网站。专用网络访问规范还将从专用网站到 localhost 的请求归类为有问题。Chrome 最终也会弃用这些 API。不过，这带来了一些略有不同的挑战，因为许多私有网站没有域名，使得弃用试用令牌的使用变得更加复杂。
CORS 预检请求
专用网络访问的第二部分是使用 CORS 预检请求来限制从安全上下文发起的专用网络请求。具体而言，即使请求是从安全上下文发起的，目标服务器也会被要求向发起者明确授权。只有在授权成功时，系统才会发送请求。
简而言之，CORS 预检请求是一个 HTTP OPTIONS 请求，其中包含一些指示后续请求的性质的 Access-Control-Request-* 标头。然后，服务器可以通过使用 Access-Control-Allow-* 标头响应 200 OK，决定是否授予精细访问权限。
如需了解详情，请参阅规范。
限制导航提取
Chrome 将弃用并最终屏蔽对专用网络的子资源请求。这不会影响导航到专用网络，专用网络还可用于 CSRF 攻击。
专用网络访问规范对这两种提取操作没有加以区分，这两种提取最终将受到相同的限制。
封面照片由 Markus Spiske 撰写（由 Unsplash 用户）