为什么 CORS 中没有针对具有标准内容类型的 POST 请求的预检 [英] Why is there no preflight in CORS for POST requests with standard content-type
问题描述
我对 CORS POST 请求的安全方面有点困惑.我知道网上丢失了有关此主题的信息，但我找不到我的问题的明确答案.
I'm a bit confused about the security aspects of CORS POST requests. I know there is a lost of information about this topic online, but I couldn't find a definite answer to my questions.
如果我理解正确的话，同源策略的目标是防止 CSRF 攻击，而 CORS 的目标是在(且仅当)服务器同意与托管在其他服务器上的应用程序共享其数据时启用资源共享网站(来源).
If I understood it correctly, the goal of the same-origin policy is to prevent CSRF attacks and the goal of CORS is to enable resource sharing if (and only if) the server agrees to share its data with applications hosted on other sites (origins).
HTTP 指定 POST 请求不是安全的"，即它们可能会改变服务器的状态，例如通过添加新评论.当使用 HTTP 方法 POST 发起 CORS 请求时，如果请求的内容类型是非标准的(或者如果存在非标准的 http 标头)，浏览器只会执行安全"的预检请求.因此，具有标准内容类型和标准标头的 POST 请求会被执行，并且可能会对服务器产生负面影响(尽管请求脚本可能无法访问响应.)
HTTP specifies that POST requests are not 'safe', i.e. they might change the state of the server, e.g. by adding a new comment. When initiating a CORS request with the HTTP method POST, the browser only performs a 'safe' preflight request if the content-type of the request is non-standard (or if there are non-standard http headers). So POST requests with standard content-type and standard headers are executed and might have negative side effects on the server (although the response might not be accessible to the requesting script.)
有一种向每个表单添加随机令牌的技术，然后服务器要求它成为每个非安全"请求的一部分.如果脚本试图伪造请求，它要么
There is this technique of adding a random token to every form, which the server then requires to be part of every non-'safe' request. If a script tries to forge a request, it either
- 没有随机令牌，服务器拒绝请求，或者
- 它尝试访问定义随机令牌的表单.这个带有随机令牌的响应应该有适当的头部字段，这样浏览器就不会授予恶意脚本访问这个响应的权限.在这种情况下，尝试也会失败.
我的结论是，针对具有标准内容类型和标头的伪造 POST 请求的唯一保护是上述技术(或类似技术).对于任何其他非安全"请求，例如 PUT 或 DELETE，或带有 json 内容的 POST，不必使用该技术，因为 CORS 执行安全"OPTIONS 请求.
My conclusion is that the only protection against forged POST requests with standard content-type and headers is the technique described above (or a similar one). For any other non-'safe' request such as PUT or DELETE, or a POST with json-content, it is not necesssay to use the technique because CORS performs a 'safe' OPTIONS request.
为什么 CORS 的作者将这些 POST 排除在预检请求之外，因此有必要采用上述技术?
Why did the authors of CORS exclude these POST exempt from preflight requests and therefore made it necessary to employ the technique described above?
推荐答案
CORS 不需要浏览器对 application/x-www-form-urlencoded、multipart/form-data 或 进行预检的原因text/plain 内容类型是，如果确实如此，那会使 CORS 比浏览器一直允许的限制更加严格(并且 CORS 的意图不是对没有 CORS 的情况下已经可能的内容施加新的限制).
The reason CORS doesn’t require browsers to do a preflight for application/x-www-form-urlencoded, multipart/form-data, or text/plain content types is that if it did, that’d make CORS more restrictive than what browsers have already always allowed (and it’s not the intent of CORS to put new restrictions on what was already possible without CORS).
也就是说，使用 CORS，您以前可以跨域执行的 POST 请求不会被预检——因为在 CORS 存在之前浏览器已经允许它们，并且服务器知道它们.因此，CORS 不会改变那些旧"类型的请求.
That is, with CORS, POST requests that you could do previously cross-origin are not preflighted—because browsers already allowed them before CORS existed, and servers knew about them. So CORS changes nothing about those "old" types of requests.
但在 CORS 之前，浏览器根本不允许您执行跨域 application/json POST，因此服务器可能会假设他们不会收到它们.这就是为什么这些类型的新"请求而不是旧"请求需要 CORS 预检 - 以提醒服务器:这是一种不同的新"请求类型，他们必须明确选择 -支持.
But prior to CORS, browsers wouldn’t allow you to do a cross-origin application/json POST at all, and so servers could assume they wouldn’t receive them. That’s why a CORS preflight is required for those types of "new" requests and not for the "old" ones—to give a heads-up to the server: this is a different "new" type of request that they must explicitly opt-in to supporting.
这篇关于为什么 CORS 中没有针对具有标准内容类型的 POST 请求的预检的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
