What is the reason behind using OPTION request before POST on CORS requests?

Question

What is the reason behind sending an OPTION request before the actual POST, UPDATE, PUT or DELETE request when a different domain is called? (So on CORS requests) I know it supposed to check whether the server can process the real request but why not send just the real request immediately?

Some of the reasons I have thought about:

1. See if the method is supported
   • Sending the real request will return the same status code, so no need to send OPTION request first.
2. Check if the user allowed to send the request
   • Make no sense as no auth headers are sent with the OPTION requests
3. Prevent heavy load on the server
   • Make no sense, as checking the auth rules is before the processing of the data.
4. To check if requested headers and origin are allowed
   • This is how it works now, but again why not just send the request, and we can read the error from the real request.
5. Prevent sending the post data, if it wont be processed
   • This is the only reason what is valid. Using options request will prevent sending the post data to the server unnecessarily. However I think this is not a problem in the 99% of the time, as only a small chunk of data is sent.

Can someone shed some light on the reasons why browser vendors implemented OPTION requests when calling a different domain?

Answer 1

CORS is a basically a browser security feature not server side.

By default the browser will NOT allow certain cross origin requests. The server you're talking to can publish whether or not it's safe to use cross origin requests but it's the client that understands and uses that information and therefore provides the protection not the server.

So for a GET request you can get the resource, check the CORS header and then decide whether to process it or not based on the header. Nice and simple.

For a POST (or other changing) event it's not so simple. You make the POST request, the server process it (remember the server doesn't care about CORS, only the browser) and sends back the response. The browser sees CORS is not enabled and ignores the response but by that point it's too late - the POST request has been processed at the server side and all that's prevented is the display of the results that it's been processed. So for an online banking application, for example, a malicious request to transfer funds means the funds will be transferred but your browser will ignore the "funds transferred successfully" response - big deal the damage is done as the money is gone and the malicious request would likely have ignored the response anyway!

So you can't send the request until you know what the CORS header will be on the response - which requires sending the request! Chicken and egg situation.

So the browser sends an OPTIONS request to the same address which doesn't change anything like a POST request might, but does return the CORS header. After that the browser knows whether it's safe to send the real request.

And btw the reason that a server doesn't implement CORS security is that it's incredibly easy to alter the Referrer header so it wouldn't offer any protection anyway. The server will have other security features (e.g. checking session is valid and authorised to make the request) but an attack that CORS is designed to prevent is one where these don't help (e.g. user is logged in to their online banking on another tab).