CSRF与CORS：明知会触发CORS错误为何仍允许请求发起？

为什么源不在白名单时，服务器返回了响应但浏览器无法读取数据？ #

CORS是浏览器层面的安全机制，服务器本身不会主动拦截跨域请求（除非你额外编写了拦截逻辑）。当源不在白名单时：

• 服务器会正常接收并处理请求，比如执行res.status(202).send(await User.find())并返回202响应。
• 浏览器收到响应后，会校验响应头中的Access-Control-Allow-Origin等CORS字段，若当前源不在允许范围内，就会触发安全拦截，禁止前端代码读取响应内容，同时在控制台抛出跨域错误，但服务器的请求处理已经完成。

为什么浏览器会向不被允许的源发送Cookie/凭据？ #

只有满足预检请求触发条件的跨域请求才会先发送OPTIONS预请求，这些条件包括：

• 请求方法不是GET/HEAD/POST
• POST请求的Content-Type不属于application/x-www-form-urlencoded、multipart/form-data、text/plain
• 请求携带自定义头信息
  如果你的请求是简单请求（比如普通GET/POST），浏览器会直接发送实际请求，包括携带的Cookie/凭据，不会先通过OPTIONS请求确认权限。这种情况下，服务器会收到请求并处理，但浏览器最终会拦截响应内容。

为什么jsfiddle的POST请求未在服务器端执行？ #

这个场景下，该POST请求大概率触发了预检OPTIONS请求：

• 浏览器先发送OPTIONS请求到服务器，服务器检查到请求源不在白名单，返回的响应不包含允许当前源的CORS头。
• 浏览器判定跨域不被允许，就会取消后续实际POST请求的发送，因此服务器根本没收到这个POST请求，自然不会执行对应的处理逻辑。

内容的提问来源于stack exchange，提问作者Dropin' Science