为公共和只读网络服务启用 CORS 是否安全？答案

【问题标题】：Is it safe to enable CORS to * for a public and readonly webservice?为公共和只读网络服务启用 CORS 是否安全？
【发布时间】：2017-08-26 12:31:15
【问题描述】：

启用CORS有几个security issues：

CSRF
受保护数据的泄露

但是，公共和只读网络服务在启用全局 CORS 方面是否存在任何问题？

Access-Control-Allow-Origin: *

我的假设：

CSRF 不相关，因为 web 服务是只读的。
窃取受保护数据无关紧要，因为 Web 服务是公开的。

【问题讨论】：

标签： security cors

【解决方案1】：

如果它是公共 API，则应为所有请求启用 CORS。公共 API 的最佳安全方法之一是在请求标头中使用应用密钥。

【讨论】：

“使用应用程序密钥”是什么意思？
发出 HTTP 请求时，请在请求中包含一个可由服务器验证的标头。因此，您的服务器将只处理具有经过身份验证的标头的请求。此标头是应用程序密钥。
应用密钥是 cookie 的替代品还是 cookie 的补充？

【解决方案2】：

这里是 something relevant from the Fetch spec（定义 CORS）：

基本安全 CORS 协议设置

对于通过 IP 身份验证或防火墙保护数据的资源（不幸的是，仍然相对常见），使用 CORS 协议是不安全的。（这就是必须发明 CORS 协议的原因。）

但是，否则使用以下标头是安全的：
Access-Control-Allow-Origin: *
即使一个资源暴露了基于 cookie 或 HTTP 认证的附加信息，使用上面的 header 也不会暴露它。它将与XMLHttpRequest 等API 共享资源，就像它已经与curl 和wget 共享一样。

因此，换句话说，如果无法从使用curl 和wget 连接到网络的随机设备访问资源，则不包含上述标头。但是，如果可以访问它，那么这样做是完全可以的。

Fetch/CORS 规范的作者更详细地介绍了in a related blog posting：

使用Access-Control-Allow-Origin: * 扩充任何资源是完全安全的，只要该资源不是 Intranet 的一部分（在防火墙后面）。换句话说，您可以使用 wget 或 curl 从 Internet 上的服务器获取 URL。对于您的基本网站，这包括网站上的所有资源。 Access-Control-Allow-Origin 标头（CORS 的一部分）告诉浏览器可以共享资源。

即使资源在请求中包含基于 cookie 或 HTTP 身份验证数据的机密信息，包括标头和共享资源仍然是安全的，因为浏览器将在没有任何 cookie 或 HTTP 身份验证数据的情况下发出请求。如果浏览器确实使用 cookie 或 HTTP 身份验证数据发出请求，它将永远不会共享资源，因为这将需要额外的标头 Access-Control-Allow-Credentials，以及上述标头的不同值。

所以继续安全地与其他应用程序共享您的公共数据！

【讨论】：