为 REST API 启用 CORS 支持答案

【问题标题】：Enabling CORS support to a REST API为 REST API 启用 CORS 支持
【发布时间】：2012-12-26 05:21:58
【问题描述】：

我试图找出为什么许多开发人员在他们的 REST API 产品中默认禁用 CORS？安全是主要问题吗？从关于 CORS 支持的W3C wiki article 看来，添加 CORS 支持相当简单（在服务器上添加一个标头 Access-Control-Allow-Origin，其值为“*”）

我最近在尝试编写一个简单的仅使用 JavaScript 的应用程序来访问 Azure 表和其他 Rest API（例如来自 Panoptix 和 ProductWIKI 的 API）时遇到了问题。他们有一些很棒的 REST API，但不允许 CORS。 Azure 表具有与其 REST API 调用相关联的严格身份验证过程，尽管如此，它不会允许 CORS（至少目前如此）。

我想听听 RESTFul API 的开发人员和管理员关于他们为您的 API 产品启用/禁用 CORS 的原因？安全/流量/兼容性是主要问题还是其他问题？

【问题讨论】：

我对服务器端的这个问题很感兴趣。对于我设置的服务 API，我通常会添加 CORS，因为它打开了从浏览器使用 API 的大门。但我想知道安全考虑是什么。我的观点是 CORS 只影响浏览器，并且只会破坏它们的同源策略，因此黑客可以抛出一个简单的代理服务器并击败 CORS。但我会对从安全角度来看对 CORS 的态度感兴趣。

标签： ajax web-services rest cors azure-table-storage

【解决方案1】：

当我创建 Web 服务时，我不使用 CORS，因为它是默认设置，并且仅在项目需要公共浏览器访问我们的服务时才添加它。为什么默认同源策略是另一个问题。我从未见过禁止从其他域访问 Ajax 的优势。

【讨论】：

“公共浏览器访问”是指通过/不通过任何身份验证的访问。在为需要身份验证的 REST API 允许 CORS 时，我应该考虑什么？
身份验证很重要，但要知道不支持 CORS 的 Web 服务仍然可以公开使用，只是不能由商业 Web 浏览器使用。同源政策不过是一道薄弱的花园大门，几乎没有提供真正的安全保障。在制作外部 Web 服务时，我更关心的是提高清晰度、文档、版本控制和可伸缩性。
CSRF 是从浏览器运行的 Web 应用程序的一个大问题。如果我们没有同源政策，我们可以在您浏览我们的网络应用程序时，使用您在另一个网络应用程序上的 cookie 代表您调用网络服务。
CSRF 是一个存在的问题，因为您可以使用非现场 JavaScript 作为脚本标签的 src 属性的属性。跨域 Ajax 不会引入任何新的安全漏洞。