Sec-Fetch-Mode instead of Preflight

Question

I created login FE and finished it. And as per usual my goto for ajax was Axios. My code is as follows.

const baseUrl = http://localhost:5000/project/us-central1/api

Axios.post(
 `${baseUrl}/v1/user/login`,
 { ...data },
 {
  headers: {
   Authorization: 'Basic auth...'
  }
 },
).then(r => console.log(r).catch(e =>console.log(e));

Now when i try to send request to my local firebase cloud function. I get a 400 bad request.

after checking the request, I was wondering why it wasn't sending any preflight request, which it should do(to the best of my knowledge) but instead I saw a header named Sec-Fetch-Mode. I searched anywhere it's a bit abstract. And I can't seem to figure anything why my request still fails.

Is there anything Im missing in my config of axios?

My FE is running on a VSCode Plugin named live server(http://127.0.0.1:5500)

Also, my firebase cloud function has enabled cors

// cloud function expres app
cors({
 origin: true
})

Any insights would be very helpful.

Answer 1

The OPTIONS request is actually being sent, because you are sending a cross-origin request with an Authorization header which is considered as non-simple. It doesn't show in developer tools because of a feature/bug in Chrome 76 & 77. See Chrome not showing OPTIONS requests in Network tab for more information.

The preflight request is a mechanism that allows to deny cross-origin requests on browser side if the server is not CORS aware (e.g: old and not maintained), or if it explicitly wants to deny cross-origin requests (in both cases, the server won't set the Access-Control-Allow-Origin header). What CORS does could be done on server side by checking the Origin header, but CORS actually protects the user at browser level. It blocks the disallowed cross-origin requests even before they are sent, thus reducing the network traffic, the server load, and preventing the old servers from receiving any cross-origin request by default.

On the other hand, Sec-Fetch-Mode is one of the Fetch metadata headers (Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site and Sec-Fetch-User). These headers are meant to inform the server about the context in which the request has been sent. Based on this extra information, the server is then able to determine if the request looks legitimate, or simply deny it. They exist to help HTTP servers mitigate certain types of attacks, and are not related to CORS.

For example the good old <img src="https://mybank.com/giveMoney?amount=9999999&[email protected]"> attack could be detected on server side because the Sec-Fetch-Dest would be set to "image" (this is just a simple example, implying that the server exposes endpoints with the GET method with unsafe cookies for money operations which is obviously not the case in real life).

As a conclusion, fetch metadata headers are not designed to replace preflight requests, but rather to coexist with them since they fulfill different needs. And the 400 error has likely nothing to do with these, but rather with the request that does not comply with the endpoint specification.