Issue with CORS error in accessing a project locally and in the deployed studio.

19 replies
Last updated: May 18, 2022
Hey, I’m trying to access my project locally (the same issue happens in the deployed studio as well) and I keep getting this error. I have added CORS Origins and allowed credentials for the local path, the deployed path, and the wildcard to try and get this working, but it keeps throwing this error.
AI Update

I can help you troubleshoot this CORS issue! Based on the error you're experiencing, here are the most common causes and solutions:

Check Your CORS Configuration

First, verify your CORS settings in the Sanity Management Dashboard:

  1. Go to your project at manage.sanity.io
  2. Navigate to Settings > API > CORS Origins
  3. Make sure you've added the exact origin URLs including the protocol

Common Mistakes to Avoid

Protocol Matters: The most frequent issue is a protocol mismatch. Make sure you're adding:

  • http://localhost:3000 (not https://localhost:3000) for local development
  • The exact port number you're using locally
  • https://your-domain.com (not http://) for your deployed site

Enable "Allow Credentials": If you're using authentication tokens with your Sanity client, you must check the "Allow credentials" checkbox for each origin. This is required when the Access-Control-Allow-Credentials header needs to be set to 'true'.

Specific Things to Try

  1. Remove the wildcard - Wildcards can sometimes cause issues. Instead, add each specific origin explicitly
  2. Check for trailing slashes - Don't include trailing slashes in your CORS origins (use http://localhost:3000, not http://localhost:3000/)
  3. Clear browser cache - CORS settings can be cached by your browser. Try hard-refreshing or opening in an incognito window
  4. Verify the exact error - Check your browser console for the specific CORS error message, as it will tell you which origin is being blocked

Studio-Specific Consideration

If you're accessing Sanity Studio itself (not just querying data), remember that:

  • The hosted Studio at yourproject.sanity.studio shouldn't need CORS configuration
  • If you're running sanity dev locally, CORS shouldn't typically apply to the Studio interface itself, only to API requests from other origins

Asset CDN Limitation

One important note: CORS settings configured in the Management Dashboard apply to the Data API but not to the Asset CDN. If you're trying to fetch assets directly from the browser, you may encounter separate CORS restrictions.

The exact error message from your browser console would help narrow down whether it's an origin mismatch, credentials issue, or something else. Look for messages like "No 'Access-Control-Allow-Origin' header is present" (origin not added) or "Access-Control-Allow-Credentials' header must be 'true'" (credentials not enabled).

Hey User! Are you using any browser extensions that could be interfering with CORS?
I don’t believe so, my only real browser extension are Vue.js devtools and Google Tag Assistant. I work for a studio with many projects, but this is the only one where it has thrown me this error.
Can you share what your CORS origins look like in manage?
yeah for sure, I hid the deployed name for client privacy but aside from that, this is my CORS Origins section:
I attempted to add the wildcard because internal navigation on the site wasn’t work (was throwing a CORS error) and I thought that might be a way to alleviate it
but since I have done that, the entire studio now fails to load
If you run
sanity cors list
in your terminal from the Studio's root folder does it contain the domains you expect?
Yes, it containse the same values, the deployed studio, the local server, and the wildcard
Did you happen to remove the your localHost domain and then re-add it?
Hi User. I love breaking stuff and haven’t been able to recreate this. I might have some good input on your local network settings but want to double check your install method. Did you use a particular starter to get started or use the sanity cli to start a new project?
Here’s a quick shot of my results just now. I created a new directory and ran sanity init inside of it - new project, blog starter - macOS, node v16 (successful):
This is on a personal account I use, gmail auth. I was already logged into the cli.
Off the wall question… would you signup email happen to start with
idco…
at gmail?
user M
yes, while trying to fix my initial page navigation cors error, one of my thoughts was to remove and re-add the allowed hosts. After doing this, the studio started completely erroring out.
user U
I also haven’t exactly been able to re-create this haha! The company I work for has many clients that all use sanity as a CMS. We follow the same set up for all of our projects, yet this is the only one that it fails with. Someone else at the company actually initialized and created the studio so I am not entirely sure the steps they went through, but we have a basic starter structure that we mimic for every project and build off of. I personally initialize it on the CLI when I create the studios. And no, the signup email does not start with idco
hmm 💭 … without digging into your project information, maybe try deleting all CORS entries and re-entering
<http://localhost:3333>
- make sure there are no spaces.
I have been playing around with this messy test studio for a while, hosting environments in gitpod, codesandbox, and extra local ports with no issues yet.
I added http://localhost :* because I saw someone who posted their own support ticket say that it worked for them and that there may be an issue with removing and re-adding CORS origins, and for the time being it has fixed it! Which is great, I can continue to work on the backend of the project!
But in the near future I will have to give our company’s client a link to access it and the deployed link is still not working
that’s super funky, please follow up if it happens again - maybe there was some mystery character junk or a random spacethat got into your cors config values that wasn’t rendering in the web form.
After putting 2 and 2 together I just thought to try https://* as a wildcard replacement to get my deployed studio running and that has solved the issue for the time being.
I don’t think there are random characters or anything like that, because they were initially working. When I removed and re-added them, the dates indicating when they were initially added all pointed to the date when they were first added and working as opposed to a new date which I figure it would do if there was some special character or space making the value of the origin different.
This would be a pretty major security risk, which I’m sure you’re aware.

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?