公开且只读的 Web 服务启用“Access-Control-Allow-Origin: *”（通配符）是否安全？

Question

启用CORS会有几个安全问题：

• 跨站请求伪造（CSRF）
• 受保护数据的曝光

但是，对于启用全局CORS的公共和只读WebService是否存在任何问题？

Access-Control-Allow-Origin: *

我的假设：

• CSRF不相关，因为webservice是只读的。
• 保护数据被盗取不相关，因为webservice是公开的。

- Matthias M

Answer 1

这里有来自Fetch规范（定义CORS）的相关内容：Basic safe CORS protocol setup

基本安全的CORS协议设置

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

然而，如果不是这种情况，使用以下标头是安全的：

Access-Control-Allow-Origin: *

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

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

Fetch/CORS规范的作者在相关博客文章中还详细介绍了这一点：

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

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

因此，放心地与其他应用程序共享您的公共数据！

- sideshowbarker

Answer 2

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

- Justus Ikara

---

“使用应用程序密钥”是什么意思？ - Matthias M

在进行HTTP请求时，请在请求中包含一个可由服务器验证的标题。因此，您的服务器仅会处理具有经过身份验证的标题的请求。该标题是应用程序密钥。 - Justus Ikara

应用程序密钥是替代Cookie的选择，还是与Cookie一起使用的选择？ - CodyBugstein