我一直在开发一个经典的 SPA，前端应用程序就位于其中app.example.com当 API 继续存在时api.example.com，因此需要使用 CORS 请求。已设置服务器返回 CORS 标头，工作正常。
每当 AJAX 请求不简单，浏览器会额外生成一个OPTIONS向服务器发出请求以确定它是否可以使用有效负载进行调用。在 MDN 上查找简单请求 https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
问题是：执行 OPTIONS 请求的实际好处是什么，特别是在安全方面？
我的应用程序的某些用户具有显着的地理延迟，并且由于预检缓存不会持续很长时间，因此预检请求会导致延迟成倍增加。
我希望能够做出POST请求简单，但只需嵌入Content-Type of application/json否定了这一点。一种可能的解决方案是使用“破解”它text/plain或 url 中的编码。因此，我希望在离开时能够充分了解 CORS 预检请求对 Web 安全的作用。谢谢。
正如您链接到的文章所述：
这些是 Web 内容可以处理的相同类型的跨站点请求
已经发出，并且没有响应数据发布给请求者
除非服务器发送适当的标头。因此，网站
防止跨站请求伪造 HTTP 没什么可怕的
访问控制。
基本上，这样做是为了确保 CORS 不会引入任何额外的方法来发出跨域请求，否则如果没有 CORS，这些请求将被阻止。
例如，如果没有 CORS，以下表单内容类型只能通过实际的跨域完成<form>标签，而不是通过 AJAX 请求：
- 应用程序/x-www-form-urlencoded
- 多部分/表单数据
- 文本/纯文本
因此，任何接收具有上述内容类型之一的请求的服务器都知道它有可能来自另一个域，并且知道采取措施来抵御诸如以下攻击：跨站请求伪造 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)。其他内容类型，例如application/json以前只能从同一域创建，因此不需要额外的保护。
类似地，带有额外标头的请求（例如X-Requested-With https://stackoverflow.com/a/22533680/413180）以前会受到类似的保护，因为它们只能来自同一域（a<form>标签无法添加额外的标头，这是以前执行跨域 POST 的唯一方法）。 GET 和 POST 也是唯一的方法由表格支持 https://www.w3.org/TR/html401/interact/forms.html#h-17.13.1。 HEAD 也列于此处，因为它的执行方式与 GET 相同，但不检索消息正文。
因此，简而言之，它将首先阻止发出“非简单”请求，而不会调用 OPTIONS 来确保客户端和服务器都在使用 CORS 语言。请记住，同源政策 https://en.wikipedia.org/wiki/Same-origin_policy仅防止来自不同来源的读取，因此仍然需要预检机制来防止发生写入 - 即不安全的方法 https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html避免在 CSRF 场景中执行。
您也许可以使用以下方法提高性能Access-Control-Max-Age标头。详情请点击此处 https://stackoverflow.com/q/25673326/413180.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
