我一直在使用经典SPA,前端应用程序位于app.example.com
,而API位于api.example.com
,因此需要使用CORS请求。设置服务器以返回CORS标头,工作正常。
每当AJAX请求不简单时,浏览器会向服务器发出额外的OPTIONS
请求,以确定它是否可以使用有效负载进行调用。 Find Simple Requests on MDN
问题是:执行OPTIONS请求的实际好处是什么,特别是在安全方面?
我的应用的某些用户具有显着的地理延迟,并且由于预检缓存不会持续很长时间,因此预检请求会导致延迟倍增。
我希望简化POST
次请求,但只是嵌入Content-Type
的{{1}}否定了这一点。一个潜在的解决方案是" hack"它通过在网址中使用application/json
或编码来实现。因此,我希望完全了解CORS预检请求对Web安全的影响。感谢。
答案 0 :(得分:2)
正如您所链接的文章所述:
这些是与Web内容相同的跨站点请求 已发出问题,并且没有响应数据发布给请求者 除非服务器发送适当的标头。因此,网站即 防止跨站点请求伪造没有什么新的担心HTTP 访问控制。
基本上这样做是为了确保CORS不会引入任何额外的方法来进行跨域请求,否则会在没有CORS的情况下阻止这些请求。
例如,如果没有CORS,以下表单内容类型只能通过实际<form>
标记跨域进行,而不能通过AJAX请求进行:
因此,任何接收具有上述内容类型之一的请求的服务器都知道它可能来自另一个域,并且知道采取措施来对抗Cross Site Request Forgery等攻击。其他内容类型(例如application/json
)以前只能来自同一个域,因此无需额外保护。
同样具有额外标头的请求(例如X-Requested-With
)之前也会受到类似的保护,因为它们只能来自同一个域(<form>
标签无法添加额外的标头,这是唯一的方法以前要做跨域POST)。 GET和POST也是唯一的方法supported by a form。此处还列出了HEAD,因为它与GET的执行方式相同,但没有检索邮件正文。
因此,简而言之,它将阻止一个非简单的&#34;首先发出请求,不调用OPTIONS以确保客户端和服务器都在谈论CORS语言。请记住,Same Origin Policy仅阻止来自不同来源的读取,因此仍需要预检机制来防止写入 - 即{CSR}场景中执行unsafe methods。
您可以使用Access-Control-Max-Age
标头提高性能。 Details here