“访问控制允许来源：*”的缺点？答案

【问题标题】：Downsides of 'Access-Control-Allow-Origin: *'?“访问控制允许来源：*”的缺点？
【发布时间】：2016-09-08 16:16:10
【问题描述】：

我有一个网站，有一个单独的静态文件子域。我发现我需要设置 Access-Control-Allow-Origin 标头才能使某些 AJAX 功能正常工作，特别是字体。我希望能够从localhost 以及www 子域访问静态子域以进行测试。简单的解决方案似乎是Access-Control-Allow-Origin: *。我的服务器使用 nginx。

您可能不希望在响应标头中为Access-Control-Allow-Origin 使用通配符的主要原因是什么？

【问题讨论】：

这允许任何基于浏览器的脚本访问您的 URL，如果您不希望这样做，那么您不会使用它。
在stackoverflow.com/a/43154277/441757 上查看答案。唯一不想使用通配符的情况是防火墙后面的 Intranet 内的资源；也就是说，您无法使用 curl 或 Postman 或其他任何方式从任何地方访问的资源。如果您可以使用 curl 或 Postman 等从任何地方访问资源，那么没有理由避免使用通配符。将通配符与需要身份验证凭据的资源一起使用也很糟糕，但即使您尝试过，您也无法做到，因为 CORS 协议不允许这样做。

标签： http nginx http-headers cors

【解决方案1】：

您可能不想在以下情况下使用通配符：

你的网站，假设它的 AJAX 后端 API 运行在不同的域上，或者只是在不同的端口上，并且你不想将后端 API 暴露给整个互联网，那么你不要发送*。例如，您的网站在 http://www.example.com 上，后端 API 在 http://api.example.com 上，那么 API 会以 Access-Control-Allow-Origin: http://www.example.com 响应。
如果 API 想从客户端请求 cookie，它不能发送Access-Control-Allow-Origin: *，但它的值必须是来自实际请求的源值。

【讨论】：

【解决方案2】：

在我看来，您可以让其他网站在未经您明确许可的情况下使用您的 API。想象一下你有一个电子商务，另一个网站可以用他们自己的外观和感觉做所有的交易，但有你的支持，对你来说，最后，这很好，因为你最终会得到钱，但你的品牌会失去它的“认可”。另一个问题可能是该网站是否会更改发送到您的后端的有效负载，例如更改交货地址和其他事情。背后的想法只是不授权未知网站使用您的 API 并向用户显示其结果。

【讨论】：

【解决方案3】：

您可以使用 hosts 文件将 127.0.0.1 映射到您的域名“dev.mydomain.com”，因为您不喜欢使用 Access-Control-Allow-Origin: *。

【讨论】：