Access-Control-Allow-Origin 头部有什么区别？

Question

什么是两者之间的区别？

add_header "Access-Control-Allow-Origin"  *;

并且

add_header "Access-Control-Allow-Origin" $http_origin always;

如果我在NGINX配置中同时使用这两个选项，会有什么影响？还是只能选择其中一个？

之前我的NGINX配置只使用了*，但用户遇到了CORS不起作用的问题，直到将其更改为$http_origin always。我不确定这两者之间的区别以及为什么更改后问题得到解决。

- halsbrew

---

请考虑接受其中一个答案。如果都不满意，请在评论中留下一些反馈。 - undefined

Answer 1

这只是两种指定来源的不同方式：

以下是表格内容：

Header Value Description "Access-Control-Allow-Origin" * 允许任何来源访问资源。我猜你已经知道这个，但以防万一，来源是协议、域名和端口的组合。所以，http://example.com、https://example.com 和 http://example.com:8080 都是不同的来源。 "Access-Control-Allow-Origin" $http_origin always 这意味着只有发出请求的特定来源才能访问资源。

在您的nginx配置中同时使用这两个可能不是一个好主意，因为CORS规范要求只有一个Access-Control-Allow-Origin头部。值得注意的是，nginx会尝试通过使用您设置的最后一个头部的值来处理此情况，但这可能会导致设置冲突。

我猜你在使用*时遇到了问题，因为一些浏览器和应用程序出于安全原因不接受通配符。我通常在涉及凭据（如cookies或HTTP身份验证）时看到这种情况。所以当你将头部设置为与请求的确切来源相同时，它被解释为比*更加严格和安全。

- PCDSandwichMan

---

整体来说是个不错的回答，但最后一句话非常误导人。只有在实施了严格的白名单时，才能准确反映来源。 - undefined

Answer 2

简而言之

add_header "Access-Control-Allow-Origin" $http_origin always;

最好情况下是不必要的，最坏情况下是危险的。

细节

[我]遇到一个用户的问题，CORS 在更改为 $http_origin always 后才工作起来 [...]

你很可能遇到了所谓的通配符异常。简而言之，通配符（*）与带有凭据的访问（例如携带 cookies 的请求）不兼容。

当你的 CORS 配置允许跨域带凭据的访问时，无条件地将请求的源头反射到Access-Control-Allow-Origin中是危险的，因为它会使你的用户面临跨域攻击的风险：

Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true

相反，您应该使用一组您真正信任的 Web 源的允许列表。

（大多数 CORS 中间件库都可以轻松实现这一点，这也是我建议在应用程序级别而不是反向代理级别上实现 CORS 的原因。）

当您的 CORS 配置仅允许匿名访问（而非带凭据的访问）时，在 Access-Control-Allow-Origin 中无条件地反映请求的来源是不必要的，因为您可以使用通配符：

Access-Control-Allow-Origin: *

- jub0bs