Dam*_* Aw 6 security ajax cross-domain
我一直在研究一个经典的 SPA，其中前端应用程序存在app.example.com而 API 存在api.example.com，因此需要使用 CORS 请求。已设置服务器以返回 CORS 标头，工作正常。
每当 AJAX 请求不简单时，浏览器都会OPTIONS向服务器发出额外请求，以确定它是否可以使用有效负载进行调用。在 MDN 上查找简单请求
问题是：执行 OPTIONS 请求的实际好处是什么，尤其是在安全方面？
我的应用程序的某些用户具有显着的地理延迟，并且由于预检缓存不会持续很长时间，因此预检请求会导致延迟成倍增加。
我希望使POST请求变得简单，但只是嵌入Content-Typeofapplication/json否定了这一点。一种潜在的解决方案是通过text/plain在 url 中使用或编码来“破解”它。因此，我希望能够充分了解 CORS 预检请求对 Web 安全的作用。谢谢。
正如您链接到的文章所述：
这些是 Web 内容已经可以发出的相同类型的跨站点请求，并且除非服务器发送适当的标头，否则不会向请求者发布任何响应数据。因此，防止跨站点请求伪造的站点不必担心 HTTP 访问控制。
基本上，这样做是为了确保 CORS 不会引入任何额外的方法来发出跨域请求，否则如果没有 CORS，这些请求将被阻止。
例如，如果没有 CORS，以下表单内容类型只能通过实际标记跨域完成<form>，而不能通过 AJAX 请求完成：
因此，任何接收具有上述内容类型之一的请求的服务器都知道该请求有可能来自另一个域，并且知道采取措施抵御诸如跨站点请求伪造之类的攻击。其他内容类型（例如application/json以前只能从同一域生成），因此不需要额外的保护。
类似地，带有额外标头（例如X-Requested-With）的请求以前也会受到类似的保护，因为它们只能来自同一域（标签<form>不能添加额外标头，这是以前执行跨域 POST 的唯一方法）。GET 和 POST 也是表单支持的唯一方法。HEAD 也列在此处，因为它的执行方式与 GET 相同，但不检索消息正文。
因此，简而言之，它将首先阻止发出“非简单”请求，而不会调用 OPTIONS 来确保客户端和服务器都在使用 CORS 语言。请记住，同源策略仅防止来自不同来源的读取，因此仍然需要预检机制来防止发生写入，即在 CSRF 场景中执行不安全的方法。
您也许可以使用Access-Control-Max-Age标头来提高性能。详细信息请参见此处。