据说，与其将所有域添加到CORS，不如只添加一组域。
然而，有时添加一组域并不简单。例如，如果我想公开一个API，那么对于每个想调用该API的域，我都需要联系我，将该域添加到允许的域列表中
我想在安全影响和减少工作量之间做出一个有意识的权衡决定
我看到的唯一安全问题是DoS攻击和CSRF攻击。
CSRF攻击已经可以通过IMG元素和表单元素实现。
与CORS相关的DoS攻击可以通过阻止referrer头上的请求来克服
我是否遗漏了安全问题
==编辑===
- 假定未设置
访问控制允许凭据标题 - 我知道如何添加给定的域列表“CORS访问”，因此我只对添加所有域“CORS访问”的安全性影响感兴趣
跨站点请求伪造攻击是访问控制允许源地址的主要问题
Ryan在内容检索方面肯定是正确的。然而，关于提出请求的问题，这里还有更多的话要说。许多网站现在提供RESTful web服务，这些服务公开了一系列可能涉及后端重大更改的功能。通常，这些RESTful服务旨在通过XHR（例如AJAX）请求调用（可能使用“单页应用程序”作为前端）。如果用户在访问恶意第三方站点时有一个允许访问这些服务的活动会话，则该站点可能会尝试在幕后调用这些REST端点，传入可能危害用户或站点的值。根据REST服务的定义，有多种方法可以防止这种情况
在针对单个页面应用的RESTWeb服务的特定情况下，您可以指定对后端REST端点的所有请求都是使用XHR发出的，并拒绝任何非XHR请求。您可以通过检查是否存在自定义请求头（类似于jQuery的X-Requested-With）来说明这一点。只有XHR类型的请求才能设置这些头；来自表单和嵌入式资源的简单GET和POST请求无法执行。最后，我们想要口述XHR请求的原因让我们回到了最初的问题——XHR请求受CORS规则的约束
如果您允许访问控制Allow Origin:，那么任何站点都可以代表用户向您的REST端点发出任何AJAX请求。如果REST端点涉及任何类型的敏感数据或允许数据持久性，则这是一个不可接受的安全漏洞。相反，如我所述，只强制执行XHR请求，并定义允许发出这些请求的源的白名单
值得指出的是，如果您的REST端点不公开任何敏感信息，或者不允许用户进行任何持久性数据更改，那么访问控制允许源代码：可能是适当的决定。例如，谷歌地图为公共地图数据提供只读视图；没有理由限制可能希望调用这些服务的第三方站点