为所有资源启用CORS会产生任何负面影响吗？

Question

CORS是一件好事。

特别是当我们从基于云的CRM调用的web服务不包含我们的域名时。

但是，它是一种纯合物吗？ 我感到有压力让我们的ReST-ish webservices的所有资源都提供CORS标题。

我很担心CORS可能会在我们的设计中暴露出一个“洞”......我的直觉是信息隐藏是使编程不会转化为意大利面条代码的原因。

有没有关于何时CORS-ifying你的资源太过分的文献？ （我没有找到任何，但我可能没有找到合适的地方）

Answer 1

根据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没有将发送域列入白名单，则永远不会提供身份验证凭据。

Answer 2

与软件工程（以及生活中）的大多数事情一样，答案取决于背景。特别是API正在服务的 以及谁正在访问API。

API服务的数据类型是什么？它是否特定于特定用户？它是用户敏感还是时间敏感的？它需要身份验证吗？

谁在访问API？它对所有人开放，还是只有一个人/组织？用户将使用哪些客户端库来访问API？从Web浏览器和JavaScript访问是否重要？

最后一个问题是最重要的：如果您的用户无需从Web浏览器访问数据，那么CORS可能不适合您的API。

想想一个图表，x轴上带有“users”，y轴上带有“data”，每个轴的范围从“受限”到“打开”：

               ^ Open
               |
               |
               |
               |
               |
USERS <------------------->
  Restricted   |        Open
               |
               |
               |
               |
               v Restricted
              DATA

您的数据和用户需求越开放（右上象限），CORS对您的API更合适。但是，这只是一般规则，您需要根据上述问题评估自己的API。