No ‘Access-Control-Allow-Origin’ header is present on the requested resource

REQUEST FROM LOCALHOST :

If Webhook in production docker container receives data from localhost:8080 POST request with fetch => JSON is parsed and Webhook response mode to last node is working perfectly :white_check_mark:

REQUEST FROM PRODUCTION ENVIRONMENT WITH CORS ENABLED :

Access to fetch at ‘https://n8n.xxx.com/webhook/4/webhook/xxx’ from origin ‘https://www.xxx.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled. :x:

It happens EVEN when access-control-allow-origin is set to “*” in the response headers.

REQUEST FROM PRODUCTION ENVIRONMENT WITH CORS DISABLED :

if Webhook receives data from https://www.xxx.com POST request with fetch and with no cors mode => :warning: no-cors forces content type to “text-plain”. Therefore I’m not getting any information from the last node

Any idea how to solve this ?

The only working solution :white_check_mark: I found for now is to add a proxy :

https://cors-anywhere.herokuapp.com/

1 Like

So just to understand you correctly. You are having the same issue as in this topic:

You can set the CORS headers but because a OPTIONS call gets made first it does not work?

Thanks. I’ve read this topic already but it does not solve my issue. I’m using fetch and I only set this in the request options :

 headers: {
       "Content-type": "application/json; charset=UTF-8",
    },

Do not understand. So you do currently not set the CORS headers in the Webhook-Node?

Whether I add ‘Access-Control-Allow-Origin’ : ‘*’ in the response headers of the webhook node or not doesn’t change anything : I always get the CORS error.

It’s the server itself that is responding with CORS error. Not the webhook. It’s not even accessing the webhook from what I see. Otherwise I’d get a response with HTTP 200 corresponding to the webhook response code/

Do you have a working example where you can call the webhook with a POST request from another public domain in the browser ? I didn’t find any.

1 Like

Sorry that I do not have the solution to your problem, I just want to recommend that you keep careful track of any changes you make to your CORS configuration. It is there to make sure that your server and code remain safe. Once you get your application running properly, please take some time to tighten up CORS so that it only allows the bare minimum required to work correctly.

I’ve seen a lot of people loosen up security while troubleshooting an issue only to forget about the changes that they made and inadvertently open up an attack vector for people with nefarious intent.

1 Like

Thanks for this message about security. Totally agree.

However if there is no way to avoid CORS errors when making POST requests to a webhook from another domain in the browser (that is not localhost), then my app isn’t really usable :slight_smile:

I have setup my own proxy as there is no other solution for now from what I read online. It’s working fine :white_check_mark:

Hey @alexsonnay,

From my perspective, I believe that setting up the proxy is the “right” way of doing it. It allows the proxy to do its job of protecting n8n!

1 Like

@alexsonnay I just tested and it works without any issues for me. I did set up a workflow with only this one webhook node:

And it allows to do this fetch request from any website:

fetch('https://jan.users.n8n.cloud/webhook/62/webhook/test', {
    method: 'post',
    body: JSON.stringify({test: 1})
  })
  .then(response => response.json())
  .then(data => console.log(data));

Do I understand your issue wrong?

1 Like

Your own example seems to work fine yes, thanks.

I’ve deployed n8n on AWS ECS with a Load balancer. Maybe that is why I get a CORS error without a proxy then.

Yes that must be the problem. n8n simply returns what it got told to do. So would also say that whatever is going wrong right now is not directly n8n related.

The error you get is due to the CORS standard, which sets some restrictions on how JavaScript can perform ajax requests.

The CORS standard is a client-side standard, implemented in the browser. So it is the browser which prevent the call from completing and generates the error message - not the server.

Postman does not implement the CORS restrictions, which is why you don’t see the same error when making the same call from Postman.

Why doesn’t Postman implement CORS? CORS defines the restrictions relative to the origin (URL domain) of the page which initiates the request. But in Postman the requests doesn’t originate from a page with an URL so CORS does not apply.

1 Like

I have a similar webhook setup, but I have a separate n8n container running in
n8n webhook mode,
and it doesn’t seem to pass through the
"options": { "responseHeaders": {...

i anyway have a solution via traefik, but i want to know if this a bug with n8n webhook mode, as it seems the default n8n headers are being sent.

can you confirm that this “should” work in webhook mode? or should i/we open an issue?