阅读各种文档(如w3c CORS)，我不得不说OPTIONS似乎根本没有得到很好的文档记录。
我想知道我的REST服务器做得是否正确，如果客户端试图访问被禁止的连接点，它会返回403(它是否存在并不总是重要的，尽管有时服务器可能会返回404。)
然而，OPTIONS文档似乎并没有推断出这样的返回代码是有效的。
我发现了这个stackoverflow问答，接受的答案似乎表明我们可以返回任何错误代码。
我想，当用户不被允许时，允许OPTIONS通过将是一个安全漏洞。同时，OPTIONS定义了Access-Control-Allow-Credentials报头，如果我在这样的连接点上返回403，我看不出如何使该报头有用。(换句话说，对我来说，这听起来很矛盾。)
简短回答：如果您确实希望OPTIONS响应在CORS启用服务器方面有用，那么您不应该仅仅因为用户没有登录就返回403。
详细信息：
服务器为OPTIONS请求返回403从来都不是无效的。CORS协议不要求服务器为OPTIONS请求返回2xx成功响应。但是，如果您的服务器没有为特定URL的OPTIONS请求返回2xx，那么CORS对该URL的预发OPTIONS请求将失败。因此，如果这正是你真正希望发生的事情，那么用403响应是可以的——用405或501响应也是可以的，或者任何其他响应代码可能具有适合你特定情况的含义。
但重要的是要记住，CORS协议要求浏览器永远不要将身份验证凭据作为CORS飞行前OPTIONS请求的一部分发送。因此，如果您的服务器被配置为需要身份验证，以便OPTIONS请求生成2xx成功响应，那么来自浏览器的所有CORS预选项将100%失败。换言之，您将确保从浏览器中运行的前端JavaScript代码到达服务器的所有请求都将失败，并添加自定义响应标头(例如，Content-Type或Authorization标头)，从而触发preflights。
我不知道使用2xx响应未经验证的OPTIONS请求(来自不允许的用户)可能会出现任何特定的安全漏洞。这不允许用户从您的服务器获得任何信息，除了您有意选择放入响应OPTIONS请求的响应标头之外。当然，这并不能阻止您要求对GET或POST或任何其他方法进行身份验证。但就CORS协议而言，这是服务器在前端JavaScript请求中指示允许使用哪些方法和请求头的唯一方法。
注意：当前积极维护的CORS需求在Fetch规范中定义https://fetch.spec.whatwg.org.这个https://w3.org/TR/corsspec已经过时，不再维护，不应该用于任何用途(请参阅https://w3.org/2017/08/16-webappsec-minutes.html#item03答案在https://stackoverflow.com/a/45926657/441757)。
我不知道为什么https://w3.org/TR/cors规范还没有被明确标记为过时，但我会尽量确保它尽快被标记为过时。