为公共和只读的Web服务启用CORS是否安全？

Question

启用CORS有几个security issues：

• CSRF
• 受保护数据的曝光

但我是否有任何公共和只读网络服务的问题，以启用全球CORS？

Access-Control-Allow-Origin: *

我的假设：

• CSRF不相关，因为webservice是readonly。
• 窃取受保护的数据无关紧要，因为网络服务是公开的。

Answer 1

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

  

基本安全CORS协议设置

     

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

     

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

Access-Control-Allow-Origin: *

     

即使资源基于cookie或HTTP身份验证公开了其他信息，使用上述标头也不会显示它。它将使用XMLHttpRequest等API共享资源，就像它已与curl和wget共享一样。

     

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

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

  

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

     

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

     

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

Answer 2

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