rest - 当当前用户禁止连接点时，我的服务器是否应该为 HTTP OPTIONS 方法返回 200？

Question

阅读各种文档(例如 w3c CORS )，我不得不说 OPTIONS 似乎根本没有得到很好的记录。

我想知道我的 REST 服务器是否做对了，如果客户端试图访问一个被禁止的连接点(它是否存在并不总是重要的，尽管有时服务器可能会返回 404。)

不过，OPTIONS 文档似乎并未推断出这样的返回码是有效的。

我找到了 this stackoverflow Q/A接受的答案似乎表明我们可以返回任何错误代码。

我认为在不允许用户时允许 OPTIONS 通过将是一个安全漏洞。同时，OPTIONS 定义了 Access-Control-Allow-Credentials header ，如果返回 403，我看不出如何使该 header 有用在这样的连接点上。 (换句话说，对我来说这听起来很矛盾。)

Answer 1

简短回答:如果您确实希望 OPTIONS 响应对支持 CORS 的服务器有用，那么您不应该仅仅因为用户未登录就返回 403。

详细信息:

服务器为 OPTIONS 请求返回 403 永远不会无效。 CORS 协议(protocol)不要求您的服务器为 OPTIONS 请求返回 2xx 成功响应。但是，如果您的服务器没有为特定 URL 的 OPTIONS 请求返回 2xx，则 CORS 预检 OPTIONS对该 URL 的请求将失败。因此，如果这确实是您想要发生的事情，那么用 403 响应就可以了——用 405 或 响应也可以501 或任何其他响应代码可能具有适合您的特定情况的含义。

但请务必记住，CORS 协议(protocol)要求浏览器永远不要将身份验证凭据作为 CORS 预检 OPTIONS 请求的一部分发送。因此，如果您的服务器配置为需要身份验证才能使 OPTIONS 请求产生 2xx 成功响应，那么来自浏览器的所有 CORS 预检将在 100% 的时间内失败.换句话说，您要确保所有从在浏览器中运行的前端 JavaScript 代码发送到服务器并添加自定义响应 header (例如，Content-Type 或 Authorization header )，以便触发预检。

我不知道用 2xx 响应未经身份验证的 OPTIONS 请求(来自不允许的用户)可能会出现任何特定的安全漏洞。这不允许用户从您的服务器获取任何信息，除了您有意选择放入您为响应 OPTIONS 请求而发送的响应 header 中的任何信息。当然，它不会阻止您要求对 GET 或 POST 或任何其他方法进行身份验证。但就 CORS 协议(protocol)而言，这是您的服务器指示它在来自前端 JavaScript 的请求中允许哪些方法和请求 header 的唯一方式。

---

另请注意:当前主动维护的 CORS 要求在 Fetch 规范中定义 https://fetch.spec.whatwg.org . https://w3.org/TR/cors规范已过时，不再维护，不应用于任何用途(参见 https://w3.org/2017/08/16-webappsec-minutes.html#item03 和 https://stackoverflow.com/a/45926657/441757 的答案)。

我不知道为什么 https://w3.org/TR/cors规范尚未明确标记为过时，但我会尽力确保它尽快被标记为过时。