CORS - What is the motivation behind introducing preflight requests?

Question

Cross-origin resource sharing is a mechanism that allows a web page to make XMLHttpRequests to another domain (from wikipedia).

I\'ve been fiddling with COR

Answer 1

I spent some time being confused as to the purpose of the preflight request but I think I've got it now.

The key insight is that preflight requests are not a security thing. Rather, they're a not-changing-the-rules thing.

Preflight requests have nothing to do with security, and they have no bearing on applications that are being developed now, with an awareness of CORS. Rather, the preflight mechanism benefits servers that were developed without an awareness of CORS, and it functions as a sanity check between the client and the server that they are both CORS-aware. The developers of CORS felt that there were enough servers out there that were relying on the assumption that they would never receive, e.g. a cross-domain DELETE request that they invented the preflight mechanism to allow both sides to opt-in. They felt that the alternative, which would have been to simply enable the cross-domain calls, would have broken too many existing applications.

There are three scenarios here:

1. Old servers, no longer under development, and developed before CORS. These servers may make assumptions that they'll never receive e.g. a cross-domain DELETE request. This scenario is the primary beneficiary of the preflight mechanism. Yes these services could already be abused by a malicious or non-conforming user agent (and CORS does nothing to change this), but in a world with CORS the preflight mechanism provides an extra 'sanity check' so that clients and servers don't break because the underlying rules of the web have changed.

2. Servers that are still under development, but which contain a lot of old code and for which it's not feasible/desirable to audit all the old code to make sure it works properly in a cross-domain world. This scenario allows servers to progressively opt-in to CORS, e.g. by saying "Now I'll allow this particular header", "Now I'll allow this particular HTTP verb", "Now I'll allow cookies/auth information to be sent", etc. This scenario benefits from the preflight mechanism.

3. New servers that are written with an awareness of CORS. According to standard security practices, the server has to protect its resources in the face of any incoming request -- servers can't trust clients to not do malicious things. This scenario doesn't benefit from the preflight mechanism: the preflight mechanism brings no additional security to a server that has properly protected its resources.

Answer 2

Pre-flight requests are necessary for requests that can change state on the server. There are 2 types of requests -

1) Calls that cannot change state on the server (like GET) - The user might get a response for the request (if the server does not check for origin) but if the requesting domain is not added to the response header Access-Control-Allow-Origin, the browser does not show the data to the user, i.e., the request is sent from the browser but the user isn't able to view/make use of the response.

2) Calls that can change state on the server (like POST, DELETE) - Since in 1), we see that the browser doesn't block the request but the response, state changing calls should not be allowed to be made without prior checks. Such calls might make changes to a trusting server that does not check the origin of the calls (called Cross Site Request Forgery), even though the response to the browser might be a failure. For this reason, we have the concept of pre-flight requests that make an OPTIONS call before any state changing calls can be sent to the server.

Answer 3

Aren't the preflighted requests about Performance? With the preflighted requests a client can quickly know if the operation is allowed before send a large amount of data, e.g., in JSON with PUT method. Or before travel sensitive data in authentication headers over the wire.

The fact of PUT, DELETE, and other methods, besides custom headers, aren't allowed by default(They need explicit permission with "Access-Control-Request-Methods" and "Access-Control-Request-Headers"), that sounds just like a double-check, because these operations could have more implications to the user data, instead GET requests. So, it sounds like:

"I saw that you allow cross-site requests from http://foo.example, BUT are you SURE that you'll allow DELETE requests? Did you consider the impacts that these requests might cause in the user data?"

I didn't understand the cited correlation between the preflighted requests and the old servers benefits. A Web Service that was implemented before CORS, or without a CORS awareness, will never receive ANY cross-site request, because first their response won't have the "Access-Control-Allow-Origin" header.

Answer 4

I feel that the other answers aren't focusing on the reason pre-fight enhances security.

Scenarios:

1) With pre-flight. An attacker forges a request from site dummy-forums.com while the user is authenticated to safe-bank.com
If the Server does not check for the origin, and somehow has a flaw, the browser will issue a pre-flight request, OPTION method. The server knows none of that CORS that the browser is expecting as a response so the browser will not proceed (no harm whatsoever)

2) Without pre-flight. An attacker forges the request under the same scenario as above, the browser will issue the POST or PUT request right away, the server accepts it and might process it, this will potentially cause some harm.

If the attacker sends a request directly, cross origin, from some random host it's most likely one is thinking about a request with no authentication. That's a forged request, but not a xsrf one. so the server has will check credentials and fail. CORS doesn't attempt to prevent an attacker who has the credentials to issue requests, although a whitelist could help reduce this vector of attack.

The pre-flight mechanism adds safety and consistency between clients and servers. I don't know if this is worth the extra handshake for every request since caching is hardy use-able there, but that's how it works.

Answer 5

CORS allows you to specify more headers and method types than was previously possible with cross-origin <img src> or <form action>.

Some servers could have been (poorly) protected with the assumption that a browser cannot make, e.g. cross-origin DELETE request or cross-origin request with X-Requested-With header, so such requests are "trusted".

To make sure that server really-really supports CORS and not just happens to respond to random requests, the preflight is executed.

Answer 6

Additionally, for HTTP request methods that can cause side-effects on user data (in particular, for HTTP methods other than GET, or for POST usage with certain MIME types), the specification mandates that browsers "preflight" the request

Source