Answers:
通过使用响应Access-Control-Allow-Origin: *，所请求的资源允许与每个来源共享。基本上，这意味着任何站点都可以向您的站点发送XHR请求并访问服务器的响应，如果您尚未实现此CORS响应，则不会这样。
因此，任何站点都可以代表其访问者向您的站点发出请求并处理其响应。如果您基于浏览器自动提供的内容（例如cookie，基于cookie的会话等）实施了诸如身份验证或授权方案之类的内容，则由第三方站点触发的请求也将使用它们。
这确实带来了安全风险，特别是如果您不仅允许共享选定资源，还允许共享每个资源的资源，则尤其如此。在这种情况下，您应该看看什么时候可以启用CORS？。
Access-Control-Allow-Origin: *这些内容时是否存在安全问题？不会有Nogin等，它们对所有人都公开吗？
Access-Control-Allow-Origin: *完全安全地添加到任何资源，除非该资源包含受非标准凭据（Cookie，基本身份验证，TLS客户端证书）以外的内容保护的私有数据。
想象一下https://example.com/users-private-data，它可能会公开私有数据，具体取决于用户的登录状态。此状态使用会话cookie。添加到该资源是安全的Access-Control-Allow-Origin: *，因为只有在没有cookie的情况下发出请求，并且需要cookie才能获取私有数据时，此标头才允许访问响应。结果，没有私有数据泄漏。
想象一下https://intranet.example.com/company-private-data，它公开了私人公司的数据，但是只有在公司的wifi网络上，才能访问该数据。这是不是安全添加Access-Control-Allow-Origin: *到这个资源，因为它使用比标准凭据以外的东西保护。否则，错误的脚本可能会将您用作通往Intranet的隧道。
想象一下，如果用户在隐身窗口中访问资源，将会看到什么。如果您对所有人都能看到此内容（包括浏览器收到的源代码）感到满意，则可以安全地添加Access-Control-Allow-Origin: *。
Access-Control-Allow-Origin: *仅允许没有 Cookie的请求。我已经对答案进行了编辑以弄清楚。
AFAIK，Access-Control-Allow-Origin只是从服务器发送到浏览器的http标头。将其限制为一个特定的地址（或禁用它）不会使您的网站更安全，例如，机器人。如果机器人愿意，他们可以忽略标题。默认情况下，常规浏览器（Explorer，Chrome等）使用标头。但是像Postman这样的应用程序只会忽略它。
当服务器端返回响应时，它实际上并不检查请求的“来源”是什么。它只是添加http标头。发送请求的是浏览器（客户端），它决定读取访问控制标头并对其执行操作。请注意，在XHR的情况下，它可以使用特殊的“ OPTIONS”请求首先请求标头。
因此，具有创意脚本功能的任何人都可以轻松忽略整个标头，无论其中设置了什么。
另请参阅设置Access-Control-Allow-Origin的可能的安全问题。
现在要实际回答问题
我忍不住觉得自己正在使我的环境面临安全风险。
如果有人想攻击您，他们可以轻松绕过Access-Control-Allow-Origin。但是通过启用“ *”，您确实可以给攻击者更多的“攻击向量”，例如，使用支持该HTTP标头的常规网络浏览器。
Access-Control-Allow-Origin *强烈建议不要在托管脚本的恶意网站上进行设置以窃取密码：-)
192.168.1.1）发出HTTP请求，并重新配置路由器以允许攻击。它甚至可以将您的路由器直接用作DDoS节点。（大多数路由器的测试页都允许ping或简单的HTTP服务器检查。这些测试页可能会被大量滥用。）
当通配符确实有问题时，这里有两个示例以注释形式发布：
假设我登录了银行的网站。如果我转到另一个页面，然后再返回银行，则由于cookie的缘故，我仍然登录。互联网上的其他用户可以在我的银行中访问与我相同的URL，但是如果没有Cookie，他们将无法访问我的帐户。如果允许跨域请求，则恶意网站可以有效地冒充用户。
– 布拉德
假设您有一个普通的家用路由器，例如Linksys WRT54g等。假设路由器允许跨域请求。我网页上的脚本可以向公用路由器IP地址（例如192.168.1.1）发出HTTP请求，并重新配置路由器以允许攻击。它甚至可以将您的路由器直接用作DDoS节点。（大多数路由器的测试页均允许ping或简单的HTTP服务器检查。这些测试页可能会被大量滥用。）
– 布拉德
我认为这些评论应该是答案，因为它们以一个真实的例子来解释问题。