CORS 安全与“访问控制-允许-起源: *”(通配符)

小开

我们需要在 CORS 限制下保持 API 服务器的安全性: 我找到的所有解决方案都告诉我允许所有来源: *，但这对我们的 API 来说将是一个重大的安全失败。

您没有解释为什么您认为它会是一个安全故障，或者为什么您需要一个严格的 CORS 策略。但是，除非(1) API 服务器运行在内部网或其他类型的防火墙之后，并且(2)对资源的访问受到 IP 授权的限制，否则使用限制性 CORS 策略不会有任何好处。返回文章页面

基本安全 CORS 协议设置

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

但是，否则使用以下标头是安全的:
Access-Control-Allow-Origin: *
即使资源公开基于 Cookie 或 HTTP 身份验证的其他信息，使用上面的头也不会显示它。它将与诸如 XMLHttpRequest之类的 API 共享资源，就像已经与 curl和 wget共享资源一样。

因此，换句话说，如果一个资源不能从使用 curl和 wget连接到 Web 的随机设备访问，那么前面提到的头就不包括在内。但是，如果可以访问它，那么完全可以这样做。

Fetch/CORS 规范的作者进一步详细介绍了在一篇相关的博客文章里:

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

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

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