CORS预检请求有哪些安全优势？(What are the security benefits of CORS preflight requests?)

CORS预检请求有哪些安全优势？(What are the security benefits of CORS preflight requests?)

我一直在研究一个经典SPA，前端应用程序位于app.example.com而API位于api.example.com ，因此需要使用CORS请求。 设置服务器以返回CORS标头，工作正常。

每当AJAX请求不简单时 ，浏览器就会向服务器发出额外的OPTIONS请求，以确定它是否可以使用有效负载进行调用。 在MDN上查找简单请求

问题是： 执行OPTIONS请求的实际好处是什么，特别是在安全方面？

我的应用程序的某些用户具有显着的地理延迟，并且由于预检缓存不会持续很长时间，因此预检请求会导致延迟倍增。

我希望简单地使POST请求，但只是嵌入Content-Type of application/json否定了这一点。 一种可能的解决方案是通过在URL中使用text/plain或encoding来“破解”它。 因此，我希望完全了解CORS预检请求对Web安全的影响。 谢谢。

I've been working on a classic SPA where the front end app lives on app.example.com while the API lives on api.example.com, hence requiring the use of CORS requests. Have setup the server to return the CORS header, works fine.

Whenever an AJAX request is not simple, the browser makes an extra OPTIONS request to the server to determine if it can make the call with the payload. Find Simple Requests on MDN

The question is: What are the actual benefits of doing the OPTIONS request, especially in regards to security?

Some users of my app have significant geographical latency and since the preflight cache doesn't last long, the preflight requests cause latencies to be multiplied.

I'm hoping to make POST requests simple, but just embedding the Content-Type of application/json negates that. One potential solution is to "hack" it by using text/plain or encoding in the url. Hence, I hope to leave with a full understanding of what CORS preflight requests do for web security. Thanks.

最满意答案

正如您链接到的文章所述：

这些是Web内容已经发出的相同类型的跨站点请求，除非服务器发送适当的标头，否则不会向请求者发送响应数据。 因此，阻止跨站点请求伪造的站点没有什么新的担心来自HTTP访问控制。

基本上这样做是为了确保CORS不会引入任何额外的方法来进行跨域请求，否则将在没有CORS的情况下阻止。

例如，如果没有CORS，以下表单内容类型只能通过实际的<form>标记跨域进行，而不能通过AJAX请求进行：

应用程序/ x-WWW窗体-urlencoded 多部分/格式数据 纯文本/

因此，任何接收具有上述内容类型之一的请求的服务器都知道它可能来自另一个域并且知道采取措施来抵御诸如跨站点请求伪造之类的攻击。 其他内容类型（例如application/json以前只能来自同一个域，因此不需要额外的保护。

类似地，带有额外标头的请求（例如X-Requested-With ）之前也会受到类似的保护，因为它们只能来自同一个域（ <form>标签不能添加额外的标头，这是以前做交叉的唯一方法-domain POST）。 GET和POST也是表单支持的唯一方法。 此处还列出了HEAD，因为它与GET的执行方式相同，但未检索到邮件正文。

因此，简而言之，它将首先停止“非简单”请求，而不调用OPTIONS以确保客户端和服务器都在谈论CORS语言。 请记住， 同源策略仅阻止来自不同来源的读取，因此仍需要预检机制来防止写入 - 即在CSRF场景中执行不安全的方法 。

您可以使用Access-Control-Max-Age标头提高性能。 细节在这里 。

As noted on the article you linked to:

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.

Basically it was done to make sure CORS does not introduce any extra means for cross-domain requests to be made that would otherwise be blocked without CORS.

For example, without CORS, the following form content types could only be done cross-domain via an actual <form> tag, and not by an AJAX request:

application/x-www-form-urlencoded multipart/form-data text/plain

Therefore any server receiving a request with one of the above content-types knows that there is a possibility of it coming from another domain and knows to take measures against attacks such as Cross Site Request Forgery. Other content types such as application/json could previously only be made from the same domain, therefore no extra protection was necessary.

Similarly requests with extra headers (e.g. X-Requested-With) would have previously been similarly protected as they could have only come from the same domain (a <form> tag cannot add extra headers, which was the only way previously to do a cross-domain POST). GET and POST are also the only methods supported by a form. HEAD is also listed here as it performs identically to GET, but without the message body being retrieved.

So, in a nutshell it will stop a "non simple" request from being made in the first place, without OPTIONS being invoked to ensure that both client and server are talking the CORS language. Remember that the Same Origin Policy only prevents reads from different origins, so the preflight mechanism is still needed to prevent writes from taking place - i.e. unsafe methods from being executed in a CSRF scenario.

You might be able to increase performance using the Access-Control-Max-Age header. Details here.