This post was most recently updated on April 28th, 2022.2 min read.
In this article, I’m listing the quick fixes to your Azure Functions suddenly throwing seemingly random and very unexpected CORS errors. I have run into this so many times that I had to list these (admittedly simple) fixes in order of importance purely for myself – but perhaps some of these will help you as well! 😁
CORS issues can be frustrating but the issue is usually, simple to fix – as long as you know what you are doing. But first, let’s take a step back – what was the issue, again?
So, long story short, you’re getting this in your browser console:
Access to fetch at 'http://localhost:7071/api/List/' from origin 'https://localhost:44343' 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.
Okay, so below are the things I’ve messed up (and then fixed):
Time needed: 10 minutes.
How to (maybe) fix your local Azure Functions CORS configuration?
- Verify your CORS origins
Okay, okay – sounds super basic, but maybe you have an issue in your CORS settings. So let’s verify the following:
– You have either the URLs of the sites hosting your front-end code OR an asterisk (“*”) in the value
– The URLs don’t end in a slash (“/”)
– The URLs are separated by a comma (“,”)
– The protocols of the URLs match (http vs https)
All good? You’ll probably have “CORS”:”*” set for local development, but for Azure Functions configuration, you should have something like this:
- Disable sending CORS credentials
This should be false by default, but it seems to me that the Azure Functions CLI sometimes has trouble remembering the default values :) I don’t know what kind of internal magic this invokes, but setting the CORSCredentials key to false has removed the issue for me once or twice.
But what does the setting do? When enabled – set to true – it enables you to send authentication details – headers, cookies, certificates – in the cross-domain requests you perform. I’ve needed this, for example, to authenticate against a SignalR hub from the front end.
This should look somewhat like the below in the local.settings.json file:
- Debug instead of running from the CLI
If you’re not doing this already, try running the Azure Functions CLI as part of debugging your solution, and make sure you’re running it with DEBUG configuration!
- Take another look at the actual URL you’re calling…
I’ve been bitten by this a couple of times now.
It sounds super basic, but you might just be calling the wrong address and the CORS error might just be something that gets thrown before you’d get a 404 (which would definitely be less confusing).
That’s it! There are probably going to be more fixes in the future, but these are something to get started with :)
- Using role claims to target WebSockets - May 24, 2022
- The simplest fixes to “500 (Internal Server Error)” from Azurite - May 17, 2022
- How to solve “Npgsql: 42883: function create_hypertable(…) does not exist”? - May 10, 2022