Access your data (CORS)

Decide which websites can access your project data.

For security reasons, your project defaults to only allow requests from localhost:3333 (the default local development server for Sanity Studio) and the hostname you used when deploying (if you used sanity deploy).

If you want to open up your project to another website, you need to add its URL to your allowed CORS origins (you can read more on browser security & CORS or the technicalities of CORS).

Typical reasons you'd want to add a new CORS origin include:

• You are using a non-default port when developing, so you'd open up to http://localhost:<your port>.
• You are deploying a studio outside the Sanity infrastructure (not using the sanity deploy command).
• You want to make it possible for a frontend to read contents from your public dataset.

A CORS origin will be defined using the following format:

protocol://hostname[:port]

The protocol and hostname are required while the port is optional when it is the default HTTP port 80.

Some valid examples include:

• https://your-domain.org
• http://localhost:3333
• http://localhost:*

Shared

When adding a CORS origin, you will also need to decide whether or not to allow credentials. If you allow credentials, the website hosted at a matching origin will be allowed to send authenticated requests using the token or session of any logged-in visitor.

If this origin hosts a studio or otherwise needs to make authenticated requests, you will need to allow credentials. Otherwise, you should probably select not to allow credentials.

Branch and pull request deploys on platforms like Vercel and Netlify get a new URL for each branch or commit, so you can't add the origin ahead of time.

If you deploy your Studio with sanity deploy, it runs on your-project.sanity.studio, which does not need any additional CORS entries. This section is for Studios you host yourself on a platform like Vercel or Netlify, and for frontend apps that query your project from the browser.

Never add a platform-wide wildcard with credentials. https://*.netlify.app or https://*.vercel.app would let any site on that platform, including ones you don't control, make authenticated requests as your logged-in users.

Scope the wildcard to a namespace you own. There’s two ways to do this, the best way first:

• Route previews to your own domain. Netlify's automatic deploy subdomains and Vercel's preview deployment suffix let you serve previews from a custom domain, like branch.previews.yourcompany.com. Then add https://*.previews.yourcompany.com. Only your deploys live under your domain, so no one else can produce a matching origin. This is the safest option, and it keeps preview auth flows behaving like production.
• Scope to your site or team on the platform's domain. If you stay on the default URLs, anchor the wildcard to the part of the URL only you control. On Netlify that's your site name, so https://*--my-studio.netlify.app matches your site's branch and preview deploys and nothing else, since the part after -- is your unique site name. On Vercel, every preview URL ends with your account or team scope slug, so anchor to that: https://*-my-team.vercel.app, where my-team is your scope slug (the slug, not the display name).

Turn on Allow credentials for these origins, since the Studio performs requests as the logged-in user. Using credentials with a wildcard that only matches domains you own and trust is fine.

A few things to keep in mind:

• On a public repo, a deploy preview built from a forked pull request still matches your site-scoped wildcard, and with credentials on it could act as a logged-in user who opens it. For public repos, disable fork deploy previews or point previews at a separate, non-production project.
• A frontend app preview that only reads public data in the browser should keep Allow credentials off, and the same scoping rules apply. If it fetches on the server instead (during SSR or build), it doesn't need a CORS origin at all.
• Remove preview origins you no longer use, the same as any other origin.

Online sandboxes like CodeSandbox, StackBlitz, CodePen, and JSFiddle run your code in the browser. That means requests to your project come from the sandbox's domain, not your own site.

To let a sandbox read your project data, add its domain as a CORS origin. That domain is the sandbox's preview URL, which is usually different from the sandbox/code editor URL. For example, you write your code at codesandbox.io, but the sandbox runs on a csb.app subdomain, and the csb.app address is the one to add. To find it, open the sandbox with your browser dev tools open and look at the Origin of the blocked request, or the origin named in the CORS error, then add that exact value.

What you add depends on the platform. JSFiddle runs every fiddle on the same host, so you add that one host. CodeSandbox gives each sandbox its own subdomain, so you add the exact subdomain your sandbox runs on:

• https://fiddle.jshell.net (JSFiddle, one fixed host)
• https://abc123-3000.csb.app (one CodeSandbox sandbox; yours will have a different ID)

Add the exact origin, not a wildcard like https://*.csb.app. A CodeSandbox subdomain changes when you fork or re-create the sandbox, so the new copy won't be allowed to fetch until you add its origin too.

Sandbox domains are shared and public. A wildcard like https://*.csb.app lets every sandbox on that platform reach your project, including ones built by people you don't know. So treat anything a sandbox can reach as public.

With that in mind:

• Don't allow credentials. If you allow credentials, any sandbox on that shared domain can make requests as anyone who is logged in to your Studio. Always leave credentials off for sandbox origins.
• Only expose public data. Have the sandbox read a public dataset. Public reads don't need a token. Don't open a private or production dataset to a shared playground.
• Keep tokens out of sandbox code. Anyone who opens the sandbox can read its code, so any token in it (read, write, or admin) is visible and usable by anyone who finds it. A read-only token does not keep data private. It's no safer than making the dataset public, and worse if the token can also read data you didn't mean to share.
• Use a proxy for private data. If a sandbox needs data from a private dataset, don't let it call your project directly. Put a small server in between that holds the token and returns only the data that should be public, then point the sandbox at that server. The private data and the token stay out of the browser.
• Remove the origin when you're done. Sandboxes are temporary, but the CORS rule stays until you delete it. Remove origins you added for experiments, so an origin you no longer use can't keep reaching your project.

Wildcards (*) are supported. A * fills in a single segment: one subdomain level or the port. For example, https://*.your-domain.org matches https://foobar.your-domain.org but not https://foo.bar.your-domain.org. The same applies to ports: http://localhost:* matches http://localhost:3000, http://localhost:8080, or any other port.

You can add a CORS origin from your management console, using the command line interface (CLI), or with Blueprints.

To add a CORS origin from your management console:

• Go to https://www.sanity.io/manage.
• Pick your project from the list.
• Go to Settings, and then to API settings.
• Under CORS Origins, click the Add CORS origin button.
• Enter your Origin, select whether or not to Allow credentials, and click Save. If your origin was added successfully, it will appear at the top of your CORS origins list.

To add a CORS origin from the CLI:

• Navigate to your project's folder in your terminal.
• Run the command sanity cors add [ORIGIN], where [ORIGIN] meets the requirements listed above.
• When prompted, select whether or not to allow credentials.

You can confirm your origin was added with the statement CORS origin added successfully or by consulting the list returned by the command sanity cors list.

You can add CORS origins as resources using Blueprints and the defineCorsOrigin helper. Follow the Define a CORS origin guide for details.