为公共的只读web服务启用“Access-Control-Allow-Origin: *”(通配符)安全吗？

Question

启用CORS有几个安全问题：

<李> CSRF < li >受保护数据的暴露

但是，公共和只读Web服务启用全球CORS有什么问题吗？

Access-Control-Allow-Origin: *

我的假设：

• CSRF不相关，因为webservice是只读的
• 窃取受保护的数据与此无关，因为webservice是公共的

Answer 1

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

Answer 2

以下是Fetch规范中的一些相关内容(它定义了CORS):

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

但是，否则使用以下标头是安全的：

Access-Control-Allow-Origin: *

即使资源公开了基于 Cookie 或 HTTP 身份验证的其他信息，使用上述标头也不会泄露它。它将与 API（如 XMLHttp 请求）共享资源，就像它已经与卷曲和卷发共享一样。

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

Fetch/CORS规范的作者在一篇相关的博客中做了更详细的介绍:

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

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

因此，请继续并安全地与其他应用程序共享您的公共数据！