在阅读各种文档（例如w3c CORS）时，我不得不说OPTIONS似乎没有那么完善的文档。
我想知道我的REST服务器是否做得正确，如果客户端尝试访问被禁止的连接点，返回403（无论是否存在，即使有时服务器也没有关系）可能会返回404。）
OPTIONS文档似乎并未推断出这样的返回码是有效的。
我发现this stackoverflow Q/A的答案似乎表明我们可以返回任何错误代码。
我想这将是一个安全漏洞，允许OPTIONS在不允许用户通过时通过。同时，OPTIONS定义了Access-Control-Allow-Credentials头，如果在这样的连接点上返回403，我看不到如何使该头有用。 （换句话说，这听起来很矛盾。）
答案 0 :(得分：2)
简短的回答：如果您确实希望OPTIONS响应对于启用CORS的服务器有用，那么您不应仅因为用户未登录而返回403。
详细信息：
对于403请求，服务器返回OPTIONS永远是无效的。 CORS协议不需要您的服务器为2xx请求返回OPTIONS成功响应。但是，如果您的服务器没有向某个特定URL返回2xx请求的OPTIONS，则对该URL的CORS预检OPTIONS请求将失败。因此，如果这是您实际上想要发生的事情，那么用403进行响应就可以了-用405或501或其他响应方式进行响应也可以代码可能具有适合您特定情况的含义。
但是请记住，CORS协议要求浏览器永远不要发送身份验证凭据，这是CORS预检OPTIONS请求的一部分。因此，如果将服务器配置为要求身份验证才能使OPTIONS请求产生2xx成功响应，则来自浏览器的所有CORS预检将在100％的时间内失败。换句话说，您将确保所有请求都将失败，这些请求将从浏览器中运行的前端JavaScript代码进入服务器并添加自定义响应标头（例如Content-Type或Authorization标头）从而触发飞行前检查。
我不知道通过用2xx响应未经身份验证的OPTIONS请求（来自不允许的用户）可能会发生任何特定的安全漏洞。这不允许用户从您的服务器中获取任何信息，超出您有意选择放入响应OPTIONS请求而发送的响应标头中的任何内容。当然，这也不会阻止您要求对GET或POST或其他任何方法进行身份验证。但是就CORS协议而言，这是服务器指出前端JavaScript请求中允许使用的方法和请求标头的唯一方法。
还请注意：当前对CORS的主动维护要求在获取规范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规范尚未明确标记为过时，但我将尽力确保将其标记为这样。