我一直在开发一个经典的 SPA,前端应用程序位于 app.example.com
而 API 存在于 api.example.com
,因此需要使用 CORS 请求。已设置服务器以返回 CORS header ,工作正常。
每当 AJAX 请求是 不简单 , 浏览器额外生成 OPTIONS
请求服务器以确定它是否可以使用有效负载进行调用。 Find Simple Requests on MDN
问题是:执行 OPTIONS 请求的实际好处是什么,尤其是在安全方面?
我的应用程序的某些用户具有显着的地理延迟,并且由于预检缓存不会持续很长时间,因此预检请求会导致延迟成倍增加。
我希望让 POST
请求简单,但只是嵌入 Content-Type
的 application/json
否定这一点。一种可能的解决方案是使用 text/plain
来“破解”它。或在 url 中编码。因此,我希望能够充分了解 CORS 预检请求对 Web 安全的作用。谢谢。
最佳答案
正如您链接到的文章所述:
These are the same kinds of cross-site requests that web content can already issue, and no response data is released to the requester unless the server sends an appropriate header. Therefore, sites that prevent cross-site request forgery have nothing new to fear from HTTP access control.
基本上这样做是为了确保 CORS 不会为跨域请求引入任何额外的方法,否则这些方法将在没有 CORS 的情况下被阻止。
例如,如果没有 CORS,以下表单内容类型只能通过实际的
<form>
跨域完成。标记,而不是通过 AJAX 请求:因此,任何接收到具有上述内容类型之一的请求的服务器都知道它可能来自另一个域,并且知道采取措施抵御诸如 Cross Site Request Forgery 之类的攻击。 .其他内容类型,例如
application/json
以前只能从同一个域中制作,因此不需要额外的保护。类似地,带有额外 header (例如
X-Requested-With
)的请求以前也会受到类似的保护,因为它们只能来自同一个域(<form>
标签不能添加额外的 header ,这是以前进行跨域的唯一方法)邮政)。 GET 和 POST 也是唯一的方法 supported by a form . HEAD 也列在此处,因为它的执行与 GET 相同,但不检索消息正文。因此,简而言之,它将首先停止发出“非简单”请求,而不会调用 OPTIONS 以确保客户端和服务器都在使用 CORS 语言。请记住 Same Origin Policy仅防止来自不同来源的读取,因此仍然需要预检机制来防止写入发生 - 即 unsafe methods从在 CSRF 场景中执行。
您可以使用
Access-Control-Max-Age
提高性能。标题。 Details here .
关于ajax - CORS 预检请求的安全优势是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35424709/