我假设默认阻止 cors 请求中的自定义标头是为了防止某种攻击。
这个假设正确吗？如果有，攻击是什么？
来自https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
在 CORS 中，发送带有 OPTIONS 方法的预检请求，因此 服务器可以响应是否可以接受发送请求 有了这些参数。 Access-Control-Request-Method 标头 作为预检请求的一部分通知服务器，当 实际请求发送，会以 POST 请求方式发送。
【问题讨论】：
标签： javascript security cors
浏览器中的跨域限制基本上旨在不允许服务器默认情况下允许脚本化的跨域 XHR/Fetch 请求执行超出浏览器已经允许使用 @987654325 发出的图像、脚本和样式表请求的任何操作@、script 和 link 元素。
当您在源 A 的文档或应用程序的 HTML 标记中放置一个 img、script 或 link 元素以嵌入来自源 B 的图像、脚本或样式表时，您无法为来自源 B 的该图像、脚本或样式表的请求设置自定义标头。
因此，脚本化的跨域 XHR/Fetch 请求的默认浏览器行为旨在基本匹配 img/script/link 发起的请求中固有的相同限制。
工作的一般原则是不要破坏某人在其服务器端代码中所做的任何假设，即他们不会接收来自在浏览器中运行的文档/应用程序的请求，这些文档/应用程序包含自定义标头或执行任何其他人可以做的事情'不要使用img/script/link。
也就是说，有几个标题 - CORS-safelisted request-headers；基本上是Accept，Accept-Language
和Content-Language — 浏览器允许您控制脚本化的跨域 XHR/Fetch 请求，但您无法控制 img/script/link 发起的请求。这些标题最终成为安全列表的原因并不是非常明确。见https://lists.w3.org/Archives/Public/public-webappsec/2013Aug/thread.html#msg44:
由于插件，接受是相当随机的。 Accept-Language 和 Content-Language 我想我们认为足够安全。不确定有 任何特别有力的理由...
最后，它看起来有些武断，因为它反映了过去 15 年 Web 平台演变的变幻莫测。
...但基本上归根结底，该集合的选择符合一般原则，即不添加任何会破坏已部署服务器中的假设的额外风险/意外。
无论如何，CORS 协议的目的是允许服务器选择加入比默认行为不那么严格的东西。因此，他们可以选择对请求标头进行不太严格的行为的具体方式是，他们可以选择发送Access-Control-Allow-Headers 并使用它来定制/调整/控制他们希望允许脚本化跨域 XHR/Fetch 的请求标头提出的要求。
但如果他们不选择发送Access-Control-Allow-Headers，那么他们可以确信浏览器不会允许来自前端 JavaScript 代码的脚本化跨域 XHR/Fetch 请求做一些令人惊讶的事情/没想到他们没有选择加入。
需要明确的是，施加默认限制的不是“CORS”。相反，这些限制只是浏览器遵循的默认同源策略的一部分，并在 https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy 和 https://en.wikipedia.org/wiki/Same-origin_policy 等地方记录。因此，CORS 只是一种允许服务器选择何时要求浏览器对特定资源使用不太严格的限制的方法。
【讨论】：