Chrome 安全策略 - 私有网络控制（CORS-RFC1918）

Chrome 安全策略又更新啦！这次 Chrome 将会逐步推进私有网络的访问控制，在 Chrome 90 将实施访问控制的第一步，如果你的程序里有从共有网络访问私有网络的需求场景，在 Chrome 90 版本更新后可能会受到影响，希望大家提前感知并做好准备！

什么是私有网络访问

Private Network Access（以前称为 CORS-RFC1918 ）限制了网站向私有网络上的服务器发送请求的能力。根据规范，此类请求只允许来自安全上下文。另外，该规范扩展了跨域资源共享（CORS）协议，因此网站现在必须在允许发送任意请求之前，必须显式请求私有网络上服务器的许可。

私有网络是指目标服务器的IP地址比从其获取请求服务器的IP地址更私有的请求。例如，从公共网站（https://example.com）向私有网站（http://router.local）的请求，或从私有网站向 localhost 的请求。

私有网络访问（CORS-RFC1918）中的公用，私用，本地网络之间的关系。

从非安全环境要求到私有网络请求已被弃用

在私有网络访问规范中，只有当启动上下文是安全的时，才允许从公共网站向私有网络的请求。如果文档以及其所有父级文档的内容都是是 HTTPS 协议，并且没有混合的内容，则该文档被认为是安全的。

因此，在 Chrome 90 中，从非安全上下文发起的对私有网络的请求被正式标记为已弃用。从 Chrome 92 开始，此类请求将被直接阻止，这是启动完整规范的第一步。

使用 Reporting API 上报弃用报告

Reporting API 是 Web 的标准日志记录功能。通过设置上报端点，网站可以指示浏览器将报告发送到指定服务端。

弃用报告是 Reporting API 支持的报告类型之一。这使网站可以在使用不推荐使用的功能时接收报告。这有助于网站跟踪将来将无法使用的内容。

从 Chrome 90 开始，每次网站从非安全上下文发起私有网络请求时，Chrome 都会将弃用报告发送到网站的报告服务端。

根据 Reporting-To Header 配置，弃用报告以 JSON 的形式发布到网站的报告端点。

DevTools 警告

从非安全上下文发起私有网络请求时，Chrome 在控制台中打印弃用警告：

从非安全上下文发起请求时， DevTools问题 面板中会显示一个问题：

Chrome 92 将直接弃用

从 Chrome 92 开始，Chrome 将直接阻止从非安全上下文发起的私有网络请求，并且将在 DevTools 控制台中记录一条 TypeError 错误。

推荐的开发人员操作

强烈建议开发者设置 Reporting-To Header ，以跟踪意外的非安全私有网络请求。这也可以警告你其他即将弃用和错误的写法。

要接收报告，你不必自己去实现上报服务端，有几种成熟的的 SaaS解决方案。

• https://report-uri.com
• https://uriports.com

Reporting-Endpoints: default="https://reporting-endpoint.glitch.me/post"
Report-To: { group: 'default', max_age: 86400, endpoints: [{ url: 'https://reporting-endpoint.glitch.me/post'}]}

未来计划

将私有网络请求限制为安全上下文只是启动私有网络访问限制的第一步。Chrome 浏览器正在努力在未来几个月内实施其余规范。

私有网络访问的第二步是使用 CORS 预检请求来控制从安全上下文发起的私有网络请求。也就是说，即使请求是从安全上下文发起的，也要求目标服务器向发起者提供明确的授权。仅在授予成功时才发送请求。

和跨域的 CORS 预检一样， 私有网络的 CORS 预检请求是一个 HTTP OPTIONS 请求，其中包含一些 Access-Control-Request-* 标头，这些标头指示后续请求的性质。然后，服务器可以决定是否或不响应授予细粒度的访问 200 OK 与 Access-Control-Allow-* Header。

了解更多：https://developer.chrome.com/blog/private-network-access-update/