"Access-Control-Allow-Origin missing in CORS" when it appears in the console

Question

I'm getting a "Cross-origin request blocked. Reason: Access-Control-allow-Origin missing in cors header" when it's visible in the console. What is causing this issue and how to resolve it?

The nginx server is set up as a proxy pass and the requests are made using lvh.me instead of localhost or 127.0.0.1.

code used to make the request :

fetch(
  'url.to/fetch',
  {
    method: 'POST',
    headers: new Headers({
      'Content-Type': 'application/json',
      'Authorization': auth
  }),
  body: JSON.stringify(body)
})
.then(response => {
  console.log(response);
  return response.json();
})
.then(data => {
  console.log('success', data);
})
.catch(error => {
  console.log('failed', error);
});

OPTIONS response headers:

    HTTP/1.1 200 OK
    Server: nginx/1.18.0 (Ubuntu)
    Date: Mon, 12 Apr 2021 13:44:53 GMT
    Content-Type: text/html; charset=utf-8
    Content-Length: 12
    Connection: keep-alive
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Origin: http://127.0.0.1:8080
    Access-Control-Allow-Headers: Authorization
    Access-Control-Allow-Methods: POST,GET,PUT,DELETE,OPTIONS

OPTIONS request headers:

Accept
    */*
Accept-Encoding
    gzip, deflate, br
Accept-Language
    fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Access-Control-Request-Headers
    authorization
Access-Control-Request-Method
    POST
Cache-Control
    no-cache
Connection
    keep-alive
DNT
    1
Host
    pubsub.warths.fr
Origin
    http://127.0.0.1:8080
Pragma
    no-cache
Referer
    http://127.0.0.1:8080/
Sec-GPC
    1
User-Agent
    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

nginx config:

server {
    server_name my.domain.name;

    location / {
        add_header 'Access-Control-Allow-Credentials' 'true';
        add_header 'Access-Control-Allow-Origin' $http_origin;
        add_header 'Access-Control-Allow-Headers' 'Authorization';
        add_header 'Access-Control-Allow-Methods' 'POST,GET,PUT,DELETE,OPTIONS';


        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_read_timeout 300;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Note: using add_header 'Access-Control-Allow-Origin' '*'; didn't fix the issue

Does this answer your question? [Why does my http://localhost CORS origin not work?](https://stackoverflow.com/questions/10883211/why-does-my-http-localhost-cors-origin-not-work) — Liam, Apr 12 '21 at 13:56
The OPTIONS request is a preflight request, it should be followed up by the real request. Does the header appear on the response to the POST request too? Is the POST request made at all? — Quentin, Apr 12 '21 at 14:00
[How do I add Access-Control-Allow-Origin in NGINX?](https://serverfault.com/questions/162429/how-do-i-add-access-control-allow-origin-in-nginx) — , Apr 12 '21 at 14:08
I tried to load the page using "lvh.me" instead of localhost or 127.0.0.1, but the result was the same, so I don't think id comes from here. — Rägnar O'ock, Apr 12 '21 at 14:14
the post request is made, but it's flagged with "CORS Missing Allow Origin" in the console but the server receives the authorization header and responds with a 401. The post response doesn't contain any "Access-Control-*" headers. — Rägnar O'ock, Apr 12 '21 at 14:18

Rägnar O'ock · Answer 1 · 2021-04-20T11:58:23.920

I played a bit with the Access-Control-Allow-* headers, and when I added the Content-Type header to the list the error disappeared. I don't know all the ramifications of it but it looks like the request was refused because it used the Content-Type header but it wasn't allowed by default.

Edit: As pointed out in the comments the Content-Type header is not considered "simple" if it's not one of the following : application/x-www-form-urlencoded, multipart/form-data or text/plain. I was using application/json so the request was rejected. Adding Content-Type to the allowed headers enables the use of nonsimple values and thus fixed the issue.

So I change :

add_header 'Access-Control-Allow-Headers' 'Authorization';

to

add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type';

This is because `Content-Type` is a non-simple request header (and there must be permitted) unless it has one of three specific values, which does not include `application/json`; see "Non-simple requests" under https://stackoverflow.com/questions/10636611/how-does-access-control-allow-origin-header-work/10636765#10636765 However, I'm unsure why the client didn't include it in the OPTIONS request. Regardless, it looks like authorizing it in the response works! — apsillers, Apr 12 '21 at 19:05

score -1 · Answer 2 · answered Apr 12 '21 at 18:41

It can be fixed by :-

Remove this part from nginx configuration :-

add_header 'Access-Control-Allow-Origin' $http_origin;

And instead of above statement write

add_header 'Access-Control-Allow-Origin' <front_end_host_address>;

suppose if your are running your front-end on http://localhost:3000, then add

add_header 'Access-Control-Allow-Origin' 'http://localhost:3000' always;

"Access-Control-Allow-Origin missing in CORS" when it appears in the console

2 Answers2