为什么CORS默认会阻止自定义标头？ [英] Why does CORS block custom headers by default?
问题描述
我认为在cors请求中默认阻止自定义标头是为了防止某种形式的攻击。</ p>
该假设正确吗？如果是这样，攻击是什么？
来自 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/OPTIONS
在CORS中，发送带有OPTIONS方法的预检请求，以便服务器可以响应
发送请求
具有这些参数。 Access-Control-Request-Method标头
作为预检请求的一部分通知服务器，当发送
实际请求时，将使用POST请求方法发送该请求。
浏览器中的跨域限制基本上旨在防止服务器允许脚本化跨域XHR / Fetch请求默认情况下，除了执行浏览器已经允许使用 img ，脚本和 link 元素。
在原始A处的文档或应用程序的HTML标记中，嵌入图像的 img ，脚本或 link 元素，原始脚本B的脚本或样式表，就无法为原始B的图像，脚本或样式表的请求设置自定义标头。
因此，脚本化跨域XHR / Fet的默认浏览器行为ch请求旨在与 img / 脚本 / link 发起的请求。
工作的一般原则是不破坏某人在其服务器端代码中所作的任何假设，即他们不会从运行在浏览器中的包含自定义标头或使用 img / script / 链接。
也就是说，有一些标头- CORS安全列出的请求标头；基本上是 Accept ， Accept-Language
和 Content-Language —浏览器允许您控制脚本化的跨域XHR / Fetch请求，但您无法控制 img / 脚本 / 链接发起的请求。这些标头最终成为安全列表集的原因并不是很明确。参见 https://lists.w3.org/Archives /Public/public-webappsec/2013Aug/thread.html#msg44 ：
由于插件的缘故，随机接受。接受语言和内容语言我想我们认为足够安全了。不确定
是否有任何特别有力的依据...
最后，它看起来有些武断，因为它反映了前15个版本中的变化情况Web平台的历史。
...但是基本上可以归结为，该集合的选择与一般原则上不添加任何会破坏已部署服务器中的假设的额外风险/意外。
无论如何，CORS协议的目的是允许服务器选择加入某些内容不如默认行为严格。因此，他们可以选择对请求标头采取不严格行为的特定方式是，他们可以选择发送 Access-Control-Allow-Headers 并使用它来定制/调整/ p精确控制他们希望允许使用脚本编写的跨域XHR / Fetch请求发出的请求标头。
但是，如果他们不选择通过发送 Access-Control-Allow-Headers ，那么他们可以确信浏览器不会允许来自前端JavaScript代码的脚本化跨域XHR / Fetch请求执行令人惊讶的操作/
很明显，不是 CORS强加了默认限制。相反，这些限制只是浏览器遵循的默认同源策略的一部分，并且在 https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy 和 https://en.wikipedia.org/wiki/Same-origin_policy 。因此，CORS只是允许服务器选择何时要求浏览器对特定资源使用较少限制的一种手段。
I assume that the default blocking of custom headers in cors requests is to prevent some kind of attack.
Is that assumption correct? If so, what's the attack?
from https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
In CORS, a preflight request with the OPTIONS method is sent, so that the server can respond whether it is acceptable to send the request with these parameters. The Access-Control-Request-Method header notifies the server as part of a preflight request that when the actual request is sent, it will be sent with a POST request method.
Cross-origin restrictions in browsers are basically designed to not cause servers to permit scripted cross-origin XHR/Fetch requests to do anything by default more than what browsers already allow for image, script, and stylesheet requests made using the img, script, and link elements.
When in the HTML markup for a document or application at origin A you put an img, script, or link element that embeds an image, script, or stylesheet from origin B, there’s no way you can set custom headers on the request for that image, script, or stylesheet from origin B.
Therefore, the default browser behavior for scripted cross-origin XHR/Fetch requests is designed to basically match the same restrictions inherent in img/script/link-initiated requests.
The general principle at work is to not break any assumptions made by somebody in their server-side code that they won’t receive requests from documents/applications running in a browser that include custom headers or that do anything else somebody can’t do using img/script/link.
That said, there are a few headers — CORS-safelisted request-headers; basically Accept, Accept-Language
and Content-Language — that browsers let you control in scripted cross-origin XHR/Fetch requests but that you have no control over for img/script/link-initiated requests. The reasons those headers ended up being the safelisted set aren’t terrifically clear-cut. See https://lists.w3.org/Archives/Public/public-webappsec/2013Aug/thread.html#msg44:
Accept is pretty random due to plugins. Accept-Language and Content-Language I guess we considered safe enough. Not sure there was any particularly strong rationale...
In the end, it looks somewhat arbitrary because it reflects the vagaries of the evolution in the previous 15 years of the Web platform.
…but basically what it came down to is, the choice of that set was in line with the general principle of not adding any additional risk/surprises that would break assumptions in deployed servers.
Anyway, the purpose of the CORS protocol is to allow servers to opt-in to something less strict than the default behavior. So the specific way they can opt in to less-strict behavior for request headers is, they can choose to send Access-Control-Allow-Headers and use that to tailor/tune/control exactly what request headers they want to allow scripted cross-origin XHR/Fetch requests to make.
But if they don’t opt-in by choosing to send Access-Control-Allow-Headers, then they can be confident that browsers aren’t going to allow scripted cross-origin XHR/Fetch requests from frontend JavaScript code to do something surprising/unexpected they have not opted-in to.
And to be clear, it’s not "CORS" that’s imposing the default restrictions. Instead those restrictions are just part of the default same-origin policy that browsers follow, and as documented in places like https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy and https://en.wikipedia.org/wiki/Same-origin_policy. So CORS is just a means for allowing servers to choose when they want to ask browsers to use less-strict restrictions for particular resources.
这篇关于为什么CORS默认会阻止自定义标头？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
