4

CORS 是个好东西。

尤其是当我们有从不包含我们域名的基于云的 CRM 调用的 Web 服务时。

但是，它是一种纯粹的商品吗？我感到压力让我们的 ReST-ish 网络服务中的所有资源都提供 CORS 标头。

我很担心 CORS 可能会在我们的设计中暴露一个“漏洞”……而我的直觉是，信息隐藏是使编程不会演变成意大利面条式代码的原因。

是否有任何关于 CORS 化您的资源何时走得太远的文献？（我还没有找到，但我可能没有在正确的地方寻找）

4

2 回答 2

2

根据 WhatWG，Access-Control-Allow-Origin: * 只要您的应用不在防火墙后面，使用就是安全的：

即使资源暴露了基于 cookie 或 HTTP 身份验证的附加信息，使用上述标头也不会泄露它。它将与 XMLHttpRequest 等 API 共享资源，就像它已经与 curl 和 wget 共享一样。

因此，换句话说，如果无法从使用 curl 和 wget 连接到网络的随机设备访问资源，则不包含上述标头。但是，如果可以访问它，那么这样做是完全可以的。

我的理解是除非设置了withCredentials标志的请求，否则不会发送 auth/cookies，如果设置了withCredentials标志，则不允许对资源进行通配符。

换句话说，如果Access-Control-Allow-Origin没有将发送域列入白名单，则永远不会提供身份验证凭据。

于 2015-08-10T16:30:48.657 回答
0

与软件工程（和生活中）的大多数事情一样，答案取决于上下文。特别是API服务内容和访问 API的人员的上下文。

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

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

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

想象一个图表，x 轴为“用户”，y 轴为“数据”，每个轴的范围从“受限”到“开放”：

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

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

于 2012-12-19T03:46:35.773 回答