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