CORS是一件好事。
特别是当我们从基于云的CRM调用的web服务不包含我们的域名时。
但是，它是一种纯合物吗？ 我感到有压力让我们的ReST-ish webservices的所有资源都提供CORS标题。
我很担心CORS可能会在我们的设计中暴露出一个“洞”......我的直觉是信息隐藏是使编程不会转化为意大利面条代码的原因。
有没有关于何时CORS-ifying你的资源太过分的文献？ （我没有找到任何，但我可能没有找到合适的地方）
答案 0 :(得分：2)
根据WhatWG，使用Access-Control-Allow-Origin: * is safe so long as your app is not behind a firewall：
即使资源基于cookie或HTTP身份验证公开了其他信息，使用上述标头也不会显示它。它将与XML（例如XMLHttpRequest）共享资源，就像它已经与curl和wget共享一样。
因此换句话说，如果不能使用curl和wget从连接到web的随机设备访问资源，则不包括上述头部。但是，如果可以访问它，那么完全没问题。
我的理解是除非请求设置为withCredentials标志，否则不会发送auth / cookies，如果设置了withCredentials标志，则不允许通配资源。
换句话说，如果Access-Control-Allow-Origin没有将发送域列入白名单，则永远不会提供身份验证凭据。
答案 1 :(得分：0)
与软件工程（以及生活中）的大多数事情一样，答案取决于背景。特别是API正在服务的 以及谁正在访问API。
API服务的数据类型是什么？它是否特定于特定用户？它是用户敏感还是时间敏感的？它需要身份验证吗？
谁在访问API？它对所有人开放，还是只有一个人/组织？用户将使用哪些客户端库来访问API？从Web浏览器和JavaScript访问是否重要？
最后一个问题是最重要的：如果您的用户无需从Web浏览器访问数据，那么CORS可能不适合您的API。
想想一个图表，x轴上带有“users”，y轴上带有“data”，每个轴的范围从“受限”到“打开”：
^ Open
|
|
|
|
|
USERS <------------------->
Restricted | Open
|
|
|
|
v Restricted
DATA
您的数据和用户需求越开放（右上象限），CORS对您的API更合适。但是，这只是一般规则，您需要根据上述问题评估自己的API。