我认为在cors请求中默认阻止自定义标头是为了防止某种攻击。
这个假设是否正确？如果是，那么攻击是什么？
来自https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS
在CORS中，发送带有OPTIONS方法的预检请求，这样就可以了 服务器可以响应是否可以发送请求 有这些参数。 Access-Control-Request-Method标头 通知服务器作为预检请求的一部分 实际请求发送后，将以POST请求方式发送。
答案 0 :(得分：5)
浏览器中的跨源限制旨在不会导致服务器允许脚本化的跨源XHR / Fetch请求默认执行任何操作，而不是浏览器已经允许使用{对图像，脚本和样式表的请求。 {1}}，img和script元素。
在源A的文档或应用程序的HTML标记中，您放置了一个嵌入来自原点B的图像，脚本或样式表的link，img或script元素，你无法在原始B的图像，脚本或样式表的请求上设置自定义标题。
因此，脚本化跨源XHR / Fetch请求的默认浏览器行为旨在匹配link / img / script标记发起的请求中固有的相同行为/限制
这里的工作原则是不要破坏某人在服务器端代码中做出的任何假设，即他们不会接收来自浏览器中运行的文档/应用程序的请求，这些文档/应用程序包含自定义标题或者做任何其他人可以做的事情。使用link / img / script。
但CORS协议的目的是允许服务器选择不那么严格的默认行为。因此，他们可以选择发送link并使用它来定制/调整/控制他们想要允许编写脚本的跨源XHR的请求头的特定方式/获取要求。
但是如果他们不选择发送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只是一种允许服务器选择何时要求浏览器对特定资源使用不太严格的限制的方法。