how to solve a cors error

What Is a CORS Error and How to Fix It (3 Ways)

If you are a web developer, I believe you have encountered a CORS error before during development when working with an API. There are around 15,400 questions about a CORS error asked on Stackoverflow 🥲:

If you haven’t, you might encounter the error at some point in your development journey. Usually, you will see an error message Access to XMLHttpRequest has been blocked by CORS policy on the browser console followed by a cause like one of these below:

• No ‘Access-Control-Allow-Origin’ header present
• No ‘Access-Control-Allow-Headers’ headers present
• Method not supported under Access-Control-Allow-Methods header

Before finding solutions to fix the error, we need to understand what is CORS.

What is CORS

The name explains itself, Cross-Origin Resource Sharing (CORS) is an HTTP mechanism that allows resource sharing from one origin to another origin securely. It is a mechanism for relaxing the same-origin policy of modern internet browsers.

Two URLs would be considered to be having different origins when they have different protocols, ports (if specified), or hosts.

For example, making a request from https://domain-a.com to https://domain-b.com/api-1 is considered cross-origin as they have different hostnames.

Internet browsers follow the same-origin policy and restrict cross-origin HTTP requests initiated from scripts. This means that a website is only allowed to make requests to the same origin unless the response from other origins includes the right CORS headers (the CORS headers will be listed in the next section of this article).

The same-origin policy is a security measure to prevent Cross-Site Request Forgery (CSRF) . Without this policy, a malicious website would be able to read your sensitive information on another website by making an HTTP request to the website.

The same-origin policy only restricts on-page scripts from accessing data or posting data to a different origin. Other resources such as images and CSS are not restricted and can be accessed from other origins.

To access data from other origins or post data to them, CORS is needed.

Why Does a CORS Error Occur

CORS supports requests and data transfers between cross-origin browsers and servers to be carried out securely. It relies on a mechanism that checks whether the server will permit requests from other origins to make sure that the cross-origin requests are safe.

Whenever a website tries to make a cross-origin request, the browser will add these CORS headers to the request:

• Access-Control-Request-Method
• Access-Control-Request-Headers

The server will return a response with some of these CORS headers to allow or block the request:

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers

A CORS error occurs when the server doesn’t return the CORS headers required.

For example, https://domain-a.com tries to make an API request to https://domain-b.com that doesn’t allow it to access its resources. As https://domain-a.com is not included in the Access-Control-Allow-Origin header of the response, the browser will display a CORS error.

How to Fix a CORS Error

Solution 1: configure the backend to allow cors.

If you have access to the backend service, you can configure the backend to handle CORS requests if they are allowed.

The basic requirement is to add Access-Control-Allow-Origin to the response header to specify the origin that is allowed to access resources from the server.

You can configure the backend to return this in the response header:

This will allow https://domain-a.com to make a cross-origin request to your server. However, only an origin can be added.

If you want to allow multiple origins, you can do it dynamically by reading the Origin header from the request and set it as the value for Access-Control-Allow-Origin .

Another option would be to set the header to Access-Control-Allow-Origin: * to allow requests from any URL. However, you need to be careful when using this as it could cause your server to be vulnerable to CSRF attacks.

Different backend frameworks need to be configured differently to add the CORS headers. This W3C Wiki shows you how to add the headers to popular servers like Apache, nginx, Jetty, etc.

If you are using an external API service and cannot configure the backend to accept CORS requests, you can try one of the methods below.

Solution 2: Use a Proxy Server

As the same-origin policy is implemented by internet browsers and not enforced within server-to-server communication, you can use a proxy server to call the external API.

A proxy server acts as a middleware between the client and the server. Instead of making a request from the client to the external API directly, you can make a request to the proxy server. The proxy server will make a request to the external API for you and return the response that it receives from the external API.

As a CORS error occurs when the external API server doesn’t return the HTTP headers required by the CORS standard, you can add the missing header like Access-Control-Allow-Origin: * and return the response to the browser using a proxy server.

You can either create your own proxy server or use a CORS proxy server like CORS Anywhere to retrieve data from the external API. One thing to note is that the CORS Anywhere proxy server is shared, it might be a bit slow sometimes. If you need to call the external API frequently, creating your own proxy server might be a better option.

Solution 3: Bypass the Error Using a Browser Extension

This method is not a proper solution to fix the error as it only works on your local computer which has the extension installed. However, you can use this method when you need to make a cross-origin request during development only.

To get rid of a CORS error, you can download a browser extension like CORS Unblock . The extension appends Access-Control-Allow-Origin: * to every HTTP response when it is enabled. It can also add custom Access-Control-Allow-Origin and Access-Control-Allow-Methods headers to the responses.

The way it gets rid of the CORS error is the same as using a CORS proxy server as mentioned above but this method only works on a computer with the extension installed. Therefore, you should not treat it as a real solution to fix a CORS error and should use it for development only.

Another thing to take note of is that all web requests will be monitored and response headers mentioned above will be appended when the extension is enabled. Therefore, you should only enable the extension when you need to use it and keep it disabled at other times.

When Not to Fix a CORS Error

Not every API can be used by a client. Some APIs are designed for server-side use, like the Google Maps Places API. If you try to access the API from a client, you will get a CORS error:

Although you could get rid of the error using one of the solutions above, Google strongly recommends developers to use the Google Map Places client library .

Many third-party API services provide client libraries to reduce the difficulty for developers to implement third-party functionality in their apps. For example, Bannerbear has client libraries in Ruby , Node.js and PHP for developers to integrate its Image Generation API into their apps easily.

If you are using a third-party API on the front-end and they have a client library, using the client library might be an easier option as you can avoid situations where you might run into a CORS error.

How to Auto-Generate Subtitles/Closed Captions for Tiktok & Instagram

In this article, we will walk you through the steps of using Bannerbear’s API to automatically generate and add closed captions to videos. This helps you to add an auto-captioning feature for videos to your video editing application easily.

How to Add Accurate Text to AI Images Using Bannerbear

Have you tried using AI to generate images with text on them and the results are not what you expected? In this article, we’ll learn how to use Bannerbear to add text to AI images automatically to overcome this limitation.

8 Free Text-to-Image AI Generator to Try in 2024

If you’re looking for a cost-effective text-to-image AI generator in 2024 for creating images for social media, blogs, e-commerce, or other purposes, consider these eight free options.

Automate & Scale Your Marketing

Bannerbear helps you auto-generate social media visuals, banners and more with our API and nocode integrations

• Generate Images via API
• Watermark Videos via API
• Generate PDFs via API
• Generate Images with Zapier
• Watermark Videos with Zapier
• Generate PDFs with Zapier
• More Use Cases
• Image Generation API
• Multi Image Generation API
• Video Generation API
• PDF Generation API
• Template Library
• Bannerbear for Enterprise

Integrations

• Airtable Integration
• Zapier Integration
• Integromat Integration
• Multi Image Demo
• AI Face Detect Demo
• Twitter to Instagram
• Real Estate Demo
• Github Social
• Smart Crop Demo
• Online Certificate Maker
• Online Wedding Invite Maker
• Online Event ID Card Maker
• Online Photo Collage Maker
• Online Invoice Maker

Docs & Guides

• Help Articles
• API Quick Start
• API Reference
• System Status
• About Bannerbear
• Open Startup
• ⤷ $10K MRR SaaS Journey
• ⤷ $10K to $20K MRR
• ⤷ Journey to $1MM ARR
• Affiliate Program
• Facebook Preview Tool
• Twitter Preview Tool
• Bannerbear Alternatives

Seamlessly o rchestrate customer identities across all your apps. Let's go >

Four Common CORS Errors and How to Fix Them

Team Descope

Chief Login Officer

March 27, 2024

Share to Twitter

Share to LinkedIn

This tutorial was written by Cameron Pavey, a full-stack developer living and working in Melbourne. You can connect with them on X to see more of their work!

Cross-Origin Resource Sharing (CORS) is a mechanism through which browsers determine whether to block frontend JavaScript code from making cross-origin requests. Cross-origin requests occur whenever your application calls an API hosted on a different origin . In practice, this is often the majority of your API calls. 

It's essential to be familiar with how CORS works because if you're not, it can quickly become a frustrating experience trying to debug why your site is not functioning as expected, especially when it might have been working fine during local development.

CORS errors can be especially common if you're developing a web application where the frontend and backend run on different origins. Perhaps you have a React application running at example.com and a corresponding REST API at api.example.com . In this case, you will likely encounter an error if you have not configured CORS correctly on your REST API server:

Before the browser initiates the desired API call (GET, POST, etc.) it first issues an OPTIONS request to the remote server that includes current origin. The response for this request will provide the browser with the relevant CORS policy headers so the browser can adhere to it accordingly.

Generally, most CORS errors can be resolved by ensuring that you have a proper, valid CORS configuration. Still, there are numerous discrete errors, each with its own cause. Mozilla MDN maintains a comprehensive list of CORS errors and how to resolve them, and it is an excellent first stop if you're debugging an obscure CORS issue. That said, some errors are more likely to happen than others, so it is good to be familiar with common errors so that you are well-equipped to solve them quickly when they come up.

In this article, you'll learn more about what causes common CORS errors and how you can fix them.

CORS Header Access-Control-Allow-Origin Missing

This error indicates that the Access-Control-Allow-Origin header is missing in the response from the backend. If you control the backend, resolving this error can be as simple as modifying the response to include the appropriate headers.

This could also occur if the initial OPTIONS request failed for some reason.

Depending on your application's architecture, there are different values you can use here. For instance, using the previous example again, even if your backend is running on api.example.com , if the frontend that will be consuming the request is running on example.com , you would use that as the origin for this header, like so:

You can also provide a wildcard as the value (using * ). However, this is advisable only if your API is intended to be public. Do not use a wildcard if it's a private, internal API.

It’s also important to note that passing credentials (cookies, auth headers, etc.) isn't allowed when using * as the value (see https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials ).

CORS Header Access-Control-Allow-Origin Does Not Match XYZ

Similar to the previous error, this one stops your frontend from being able to consume the request. However, rather than a total lack of a CORS header, this error indicates that the header is present but the permitted origin does not match the origin making the request.

In this case, ensure that the following are true:

The response contains the header.

There is only one such header without duplicates.

The header contains only a single origin.

The origin matches the requester's origin.

If these points are all true, this error should be resolved.

CORS Request Not HTTP

This error happens because CORS can be used only with the HTTP or HTTPS URL schemes. However, an asset is loaded through a different scheme—commonly, file://. This most often happens when viewing a site through the local file system—opening the file directly in your browser—rather than as an asset served via HTTP(S) from a web server.

This often happens when you want to perform local testing or development. However, since CORS doesn't support this behavior, it is now advised that local testing be done with a local server as this resolves the issue and makes the experience closer to how it would be in an actual live environment.

Multiple CORS Header Access-Control-Allow-Origin Not Allowed

This error indicates that the server has sent more than one Access-Control-Allow-Origin header in the response. This is invalid as you should include only a single instance of this header. Additionally, the header's value should only be a single origin or `null`. You cannot provide a list of origins here.

This may seem problematic if you'd like to allow multiple origins. Consider a case where you have an internal API that needs to be consumed by numerous clients. In that case, you can implement checks in either your application code or your web server (like Nginx or Apache) to determine if the requester's origin is one that you approve of and, if so, reflect the appropriate value in the header.

Other ways to bypass CORS errors

Sometimes, during early development or when working with a backend that you cannot easily change, you may wish you could bypass CORS errors for a while to get on with development. 

Warning: While understanding how to bypass CORS can be beneficial for development and debugging purposes, it's crucial to use this practice cautiously due to its security risks. It's recommended you only employ CORS bypass techniques temporarily and only when managing servers under your control. Avoid using these methods for regular web browsing activities.

Disable browser security

As the browser enforces CORS, it can be circumvented client-side without any changes to the server. If you use Google Chrome or a related variant, disabling your browser's web security features is the easiest way to do this without additional dependencies. This should be done only for development and testing, and you should not use the browser in this state for normal web activities.

To disable web security in Chrome, you can use the following commands:

For Windows, create a new shortcut and set its target as follows:

Use a browser extension

You can also bypass CORS using a browser extension. These extensions edit the response on its way back to your browser and inject the necessary header and value so that your browser accepts it. Such extensions are available for numerous browsers, including the following:

Chrome-like browsers

Use a proxy

Finally, you can bypass CORS by routing your requests via a proxy. Proxies designed for this purpose handle the request on your behalf before returning a response to your browser with the appropriate headers. This can be a reasonable, low-effort way to check particular requests without CORS restrictions. However, routing your requests through a third-party proxy brings inherent risks, so it isn't advisable as a long-term solution.

When not to bypass CORS errors

As you've seen, CORS can be easily bypassed. Indeed, it's enforced only in the browser, so you may be wondering what the point of it is and whether you can (or should) bypass it all the time.

CORS is a valuable web technology that plays a role in mitigating attacks like cross-site request forgery (CSRF) . You should disable CORS only for testing and development and, even then, only temporarily. 

Consider a case where you use an API intended to be consumed only by backend services. This API might explicitly NOT permit any origins in its CORS headers as this would stop browsers from consuming the API. At the same time, backend services would be free to use the API as they do not typically implement CORS. Suppose you bypassed this restriction by using a proxy so your frontend app can call this API. While this may technically work, you may be exposing credentials and data on the frontend that are never intended to be there, leading to potential security concerns.

A preferable alternative to disabling CORS is implementing it correctly on your backend or web server. With a proper configuration, any reasonable setup should work correctly without bypassing or disabling CORS.

Wrapping up

In this article, you've been introduced to CORS. You've learned about what it is and what its role is in web security. You've seen a few of the most common CORS errors, what causes them, how to resolve them, and a few other ways in which CORS can be bypassed, as well as some pointers on when not to bypass it. 

CORS is a valuable web technology, but it can be frustrating when it's the source of errors that may not be easy to understand if you haven't dealt with them before. By familiarizing yourself with CORS, you put yourself in the best position to deal with it appropriately when errors occur.

For more developer tips, subscribe to the Descope blog .

Liked what you saw?

Check out these posts next.

Add Authentication & Authorization to a React App With Desco...

Read More >

Developers | Feb 29, 2024

OpenID vs OAuth: Understanding the Difference

Auth Thoughts | Jun 26, 2023

The Developer’s Guide to Refresh Token Rotation

Developers | Mar 15, 2024

Copyright © Descope Inc. All rights reserved.

October 26, 2021

Cors errors and how to solve them.

Love to compete?

Join Topcoder Challenges

CORS is an abbreviation for Cross-Origin Response Sharing. It is what allows the website on one URL to request data from a different URL, and it frustrates both the frontend and backend devs alike. You might’ve added an image URL only to end up with something like this.

Or, your API fails and shows a CORS error in the console.

This happens because the same-origin policy is part of the browser’s security model which allows websites to request data from APIs of the same URL but blocks those of different URLs. Browsers do this by adding an ORIGIN key in the request.

However, let’s say if the server was on bar.com then the browser will prevent showing this to the client because it had a cross-origin response.

Why is CORS blocked?

It is to prevent cross-site request forgery. Let’s say you log in to facebook.com and your browser stores the authentication token so that in the future you get logged in automatically. And for every request to the origin facebook.com , these auth-token headers will be present. Now imagine a scenario where you click on a pop-up opening badSite.com . They also have the ability to make requests to facebook.com . In this case, the browser will add related cookies and your token will be shared with badSite.com , and your account has been successfully hacked with a cross-site request forgery attack. To prevent this the CORS error was introduced.

How do we solve these issues?

The first method is the quickest, but it is not the right way. It is mostly used during development when you need to start implementing the API quickly and can wait a bit for the final production build. As you might have guessed, we are going to tell the browser to stop caring about these errors. This can be done by installing a chrome extension .

Once installed, click on it and make sure it says on. Once done just refresh your app.

Why is this fix a deceiving one?

As you can see, whatever this extension did was to stop YOUR browser from checking the CORS error. But when you deliver it to your client this won’t work.

Solving CORS error the right way

Now, If you are in control of the server then lucky for you because you actually have some power to solve this. But if not, then you are out of luck.

For example, if you want to solve this on the express.js then all you have to do is use a certain middleware that will handle the origin key.

But, for any non-standard HTTP request like PUT, PATCH, DELETE, you’ll have to preflight them. The term preflight is used because it’s like a security check before you board a plane to make sure the passengers (or request) are safe to deploy on the airplane (or server) or not. The neat thing is that the browser automatically knows when to preflight and the server responds accordingly whether these non-standard requests are allowed or not.

And at this point, these requests can happen properly. This sounds inefficient, because your service will have to deal with this at every request but the server has an option to respond with a header called Access-Control-Max-Age:86400 which will keep these details saved for the specified time.

Still facing a CORS error?

Open a network tab in your console.

In the response header look for the Access-Control-Allow-Origin header. If it does not exist then add it as a middleware in the way we discussed above. If it does exist then make sure there is no URL mismatch with the website. And if all is fine then check whether it is a non-standard HTTP request and you need to allow them.

How to allow from multiple origin domains:

Let’s say in your express app you only want to allow requests from www.example1.com www.example2.com and www.example3.com . You will do it in the following way with the help of middleware.

Now, let’s look at the Access-Control header family with a bit of detail. You can do various things and put several restrictions with their help. For example you can allow only certain types of requests in the following way.

res. header ( 'Access-Control-Allow-Methods' , 'GET, POST' );

This will allow only GET and POST requests. If you want to fix the headers that can be sent by client then you can do that in the following way.

res.header( 'Access -Control-Allow-Headers', 'Content - Type , Authorization');

If you want the browser to expose things like cookies/authorization headers, or the TLS client certificates then you can do that in the following way.

res. header ( 'Access-Control-Allow-Credentials' , true );

These are some of the popular Access-Control header family members. Goodbye.

Recommended for you

Routing in express.js, python fastapi, private edge video enablement quickstart.

Fixing Common Problems with CORS and JavaScript

Many websites have JavaScript functions that make network requests to a server, such as a REST API. The web pages and APIs are often in different domains. This introduces security issues in that any website can request data from an API. Cross-Origin Resource Sharing (CORS) provides a solution to these issues. It became a W3C recommendation in 2014. It makes it the responsibility of the web browser to prevent unauthorized access to APIs. All modern web browsers enforce CORS. They prevent JavaScript from obtaining data from a server in a domain different than the domain the website was loaded from, unless the REST API server gives permission.

From a developer’s perspective, CORS is often a cause of much grief when it blocks network requests. CORS provides a number of different mechanisms for limiting JavaScript access to APIs. It is often not obvious which mechanism is blocking the request. We are going to build a simple web application that makes REST calls to a server in a different domain. We will deliberately make requests that the browser will block because of CORS policies and then show how to fix the issues. Let’s get started!

NOTE : The code for this project can be found on GitHub .

Table of Contents

Prerequisites to Building a Go Application

How to build a simple web front end, how to build a simple rest api in go, how to solve a simple cors issue, allowing access from any origin domain, cors in flight, what else does cors block, restrictions on response headers, credentials are a special case, control cors cache configuration, how to prevent cors issues with okta, how cors prevents security issues.

First things first, if you don’t already have Go installed on your computer you will need to download and install the Go Programming Language .

Now, create a directory where all of our future code will live.

Finally, we will make our directory a Go module and install the Gin package (a Go web framework) to implement a web server.

A file called go.mod will get created containing the dependencies.

We are going to build a simple HTML and JavaScript front end and serve it from a web server written using Gin.

First of all, create a directory called frontend and create a file called frontend/index.html with the following content:

The web page has a text area to display messages and a simple form with two buttons. When a button is clicked it calls the JavaScript function onGet() passing it a version number. The idea being that v1 requests will always fail due to CORS issues, and v2 will fix the issue.

Next, create a file called frontend/control.js containing the following JavaScript:

The onGet() function inserts the version number into the URL and then makes a fetch request to the API server. A successful request will return a list of messages. The messages are displayed in the text area.

Finally, create a file called frontend/.go containing the following Go code:

This code simply serves the contents of the frontend directory on requests on port 8080. Note that JavaScript makes a call to port http://localhost:8000 which is a separate service.

Start the server and point a web browser at http://localhost:8080 to see the static content.

Create a directory called rest to contain the code for a basic REST API.

NOTE: A separate directory is required as Go doesn’t allow two program entry points in the same directory.

Create a file called rest/server.go containing the following Go code:

A list called messages is created to hold message objects.

The function GetMessages() is called whenever a GET request is made to the specified URL. It returns a JSON string containing the messages. The URL contains a path parameter which will be v1 or v2 . The server listens on port 8000.

The server can be run using:

We now have two servers—the front-end one on http://localhost:8080 , and the REST API server on http://localhost:8000 . Even though the two servers have the same hostname, the fact that they are listening on different port numbers puts them in different domains from the CORS perspective. The domain of the web content is referred to as the origin. If the JavaScript fetch request specifies cors a request header will be added identifying the origin.

Make sure both the frontend and REST servers are running.

Next, point a web browser at http://localhost:8080 to display the web page. We are going to get JavaScript errors, so open your browser’s developer console so that we can see what is going on. In Chrome it is *View** > Developer > Developer Tools .

Next, click on the Send v1 button. You will get a JavaScript error displayed in the console:

Access to fetch at ‘http://localhost:8000/api/v1/messages’ from origin ‘http://localhost:8080’ has been blocked by CORS policy: 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.

The message says that the browser has blocked the request because of a CORS policy. It suggests two solutions. The second suggestion is to change the mode from cors to no-cors in the JavaScript fetch request. This is not an option as the browser always deletes the response data when in no-cors mode to prevent data from being read by an unauthorized client.

The solution to the issue is for the server to set a response header that allows the browser to make cross-domain requests to it.

This tells the web browser that the cross-origin requests are to be allowed for the specified domain. If the domain specified in the response header matches the domain of the web page, specified in the Origin request header, then the browser will not block the response being received by JavaScript.

We are going to set the header when the URL contains v2 . Change the GetMessages() function in cors/server.go to the following:

This sets a header to allow cross-origin requests for the v2 URI.

Restart the server and go to the web page. If you click on Get v1 you will get blocked by CORS. If you click on Get v2 , the request will be allowed.

A response can only have at most one Access-Control-Allow-Origin header. The header can only specify only one domain. If the server needs to allow requests from multiple origin domains, it needs to generate an Access-Control-Allow-Origin response header with the same value as the Origin request header.

There is an option to prevent CORS from blocking any domain. This is very popular with developers!

Be careful when using this option. It will get flagged in a security audit. It may also be in violation of an information security policy, which could have serious consequences!

Although we have fixed the main CORS issue, there are some limitations. One of the limitations is that only the HTTP GET, and OPTIONS methods are allowed. The GET and OPTIONS methods are read-only and are considered safe as they don’t modify existing content. The POST, PUT, and DELETE methods can add or change existing content. These are considered unsafe. Let’s see what happens when we make a PUT request.

First of all, add a new form to client/index.html :

This form has a text input and the two send buttons as before that call a new JavaScript function.

Next, add the JavaScript funtion to client/control.js :

This makes a PUT request sending the form parameters in the request body. Note that the URI ends in /0 . This means that the request is to create or change the message with the identifier 0 .

Next, define a PUT handler in the main() function of rest/server.go :

The message identifier is extracted as a path parameter.

Finally, add the request handler function to rest/server.go :

This updates the message from the form data and sends the new list of messages. The function also always sets the allow origin header, as we know that it is required.

Now, restart the servers and load the web page. Make sure that the developer console is open. Add some text to the text input and hit the Send v1 button.

You will see a slightly different CORS error in the console:

Access to fetch at ‘http://localhost:8000/api/v1/messages/0’ from origin ‘http://localhost:8080’ 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.

This is saying that a preflight check was made, and that it didn’t set the Access-Control-Allow-Origin header.

Now, look at the console output from the API server:

So, what is happening here? JavaScript is trying to make a PUT request. This is not allowed by CORS policy. In the GET example, the browser made the request and blocked the response. In this case, the browser refuses to make the PUT request. Instead, it sent an OPTIONS request to the same URI. It will only send the PUT if the OPTIONS request returns the correct CORS header. This is called a preflight request. As the server doesn’t know what method the OPTIONS preflight request is for, it specifies the method in a request header:

Let’s fix this by adding a handler for the OPTIONS request that sets the allow origin header in cors/server.go :

Notice that the OPTIONS handler is only set for the v2 URI as we don’t want to fix v1 .

Now, restart the server and send a message using the Put v2 button. We get yet another CORS error!

Access to fetch at ‘http://localhost:8000/api/v2/messages/0’ from origin ‘http://localhost:8080’ has been blocked by CORS policy: Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.

This is saying that the preflight check needs another header to stop the PUT request from being blocked.

Add the response header to cors/server.go :

Restart the server and resend the message. The CORS issues are resolved.

CORS has a very restrictive policy regarding which HTTP request headers are allowed. It only allows safe listed request headers. These are Accept , Accept-Language , Content-Language , and Content-Type . They can only contain printable characters and some punctuation characters are not allowed. Header values can’t have more than 128 characters.

There are further restrictions on the Content-Type header. It can only be one of application/x-www-form-urlencoded , multipart/form-data , and text/plain . It is interesting to note that application/json is not allowed.

Let’s see what happens if we send a custom request header. Modify the onPut() function in frontend/control.js to set a header:

Now, make sure that the servers are running and load or reload the web page. Type in a message and click the Put v1 button. You will see a CORS error in the developer console.

Access to fetch at ‘http://localhost:8000/api/v2/messages/0’ from origin ‘http://localhost:8080’ has been blocked by CORS policy: Request header field x-token is not allowed by Access-Control-Allow-Headers in preflight response.

Any header which is not CORS safe-listed causes a preflight request. This also contains a request header that specifies the header that needs to be allowed:

Note that the header name x-token is specified in lowercase.

The preflight response can allow non-safe-listed headers and can remove restrictions on safe listed headers:

Next, change the function in cors/server.go to allow the custom header:

Restart the server and resend the message by clicking the Put v2 button. The request should now be successful.

CORS also places restrictions on response headers. There are seven whitelisted response headers: Cache-Control , Content-Language , Content-Length , Content-Type , Expires , Last-Modified , and Pragma . These are the only response headers that can be accessed from JavaScript. Let’s see this in action.

First of all, add a text area to frontend/index.html to display the headers:

Next, replace the first then block in the onPut function in frontend/control.js to display the response headers:

Finally, set a custom header in rest/server.go :

Now, restart the server and reload the web page. Type in a message and hit Put v2 . You should see some headers displayed, but not the custom header. CORS has blocked it.

This can be fixed by setting another response header to expose the custom header in server/server.go :

Restart the server and reload the web page. Type in a message and hit Put v2 . You should see some headers displayed, including the custom header. CORS has now allowed it.

There is yet another CORS blocking scenario. JavaScript has a credentials request mode. This determines how user credentials, such as cookies are handled. The options are:

• omit : Never send or receive cookies.
• same-origin : This is the default, that allows user credentials to be sent to the same origin.
• include : Send user credentials even if cross-origin.

Let’s see what happens.

Modify the fetch call in the onPut() function in frontend/Control.js :

Now, make sure that the client and server are running and reload the web page. Send a message as before. You will get another CORS error in the developer console:

Access to fetch at ‘http://localhost:8000/api/v2/messages/0’ from origin ‘http://localhost:8080’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: The value of the ‘Access-Control-Allow-Credentials’ header in the response is ‘’ which must be ‘true’ when the request’s credentials mode is ‘include’.

The fix for this is to add another header to both the OptionMessage() , and PutMessage() functions in cors/server.go as the header needs to be present in both the preflight request and the actual request:

The request should now work correctly.

The credentials issue can also be resolved on the client by setting the credentials mode to omit and sending credentials as request parameters, instead of using cookies.

The is one more CORS header that hasn’t yet been discussed. The browser can cache the preflight request results. The Access-Control-Max-Age header specifies the maximum time, in seconds, the results can be cached. It should be added to the preflight response headers as it controls how long the Access-Control-Allow-Methods and Access-Control-Allow-Headers results can be cached.

Browsers typically have a cap on the maximum time. Setting the time to -1 prevents caching and forces a preflight check on all calls that require it.

Authentication providers, such as Okta, need to handle cross-domain requests to their authentication servers and API servers. This is done by providing a list of trusted origins. See Okta Enable CORS for more information.

CORS is an important security feature that is designed to prevent JavaScript clients from accessing data from other domains without authorization.

Modern web browsers implement CORS to block cross-domain JavaScript requests by default. The server needs to authorize cross-domain requests by setting the correct response headers.

CORS has several layers. Simply allowing an origin domain only works for a subset of request methods and request headers. Some request methods and headers force a preflight request as a further means of protecting data. The actual request is only allowed if the preflight response headers permit it.

CORS is a major pain point for developers. If a request is blocked, it is not easy to understand why, and how to fix it. An understanding of the nature of the blocked request, and of the CORS mechanisms, can easily overcome such issues.

If you enjoyed this post, you might like related ones on this blog:

• What is the OAuth 2.0 Implicit Grant Type?
• Combat Side-Channel Attacks with Cross-Origin Read Blocking

Follow us for more great content and updates from our team! You can find us on Twitter , Facebook , subscribe to our YouTube Channel or start the conversation below.

Okta Developer Blog Comment Policy

We welcome relevant and respectful comments. Off-topic comments may be removed.

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption
• Start Monitoring for Free

The ultimate guide to enabling Cross-Origin Resource Sharing (CORS)

Consider the following situation: you’re trying to fetch some data from an API on your website using fetch() but end up with an error.

You open up the console and see either “No Access-Control-Allow-Origin header is present on the requested resource,” or “The Access-Control-Allow-Origin header has a value <some_url> that is not equal to the supplied origin” written in red text, indicating that your request was blocked by CORS policy.

Seem familiar? With over 10,000 questions posted under the cors tag on StackOverflow, it is one of the most common issues that plague frontend developers and backend developers alike. So, what exactly is the CORS policy and why do we face this error often?

What is Cross-Origin Resource Sharing (CORS)?

Interestingly, this is not an error as we portray it, but rather the expected behavior. Our web browsers enforce the same-origin policy , which restricts resource sharing across different origins. Cross-origin resource sharing , or CORS, is the mechanism through which we can overcome this barrier. To understand CORS, let us first understand the same-origin policy and its need.

The same-origin policy

In simple terms, the same-origin policy is the web version of “don’t talk to strangers” incorporated by the browser.

All modern web browsers available today follow the same-origin policy that restricts how XMLHttpRequest and fetch requests from one origin interact with a resource from another origin. What’s an origin, exactly?

It’s the combination of a scheme, domain, and port. The scheme could be HTTP, HTTPS, FTP, or anything else. Similarly, the port can also be any valid port number. Same-origin requests are essentially those requests whose scheme, domain, and port match. Let’s look at the following example.

Assuming our origin is http://localhost:3000 , the requests can be categorized into same-origin or cross-origin requests as follows:

This is the reason why your frontend running on http://localhost:3000 cannot make API calls to your server running http://localhost:5000 or any other port when you develop single-page applications (SPAs).

Also, requests from origin https://mywebsite.com to origin https://api.mywebsite.com are still considered cross-site requests even though the second origin is a subdomain.

Due to the same-origin policy, the browser will automatically prevent responses from cross-origin requests from being shared with the client. This is great for security reasons! But not all websites are malicious and there are multiple scenarios in which you might need to fetch data from different origins, especially in the modern age of microservice architecture where different applications are hosted on different origins.

This is a great segue for us to deep dive into CORS and learn how to use it in order to allow cross-origin requests.

Allowing cross-site requests with CORS

We’ve established that the browser doesn’t allow resource sharing between different origins, yet there are countless examples where we are able to do so. How? This is where CORS comes into the picture.

CORS is an HTTP header-based protocol that enables resource sharing between different origins. Alongside the HTTP headers, CORS also relies on the browser’s preflight-flight request using the OPTIONS method for non-simple requests. More on simple and preflight requests later in this article.

Because HTTP headers are the crux of the CORS mechanism, let’s look at these headers and what each of them signifies.

Access-Control-Allow-Origin

The Access-Control-Allow-Origin response header is perhaps the most important HTTP header set by the CORS mechanism. The value of this header consists of origins that are allowed to access the resources. If this header is not present in the response headers, it means that CORS has not been set up on the server.

Over 200k developers use LogRocket to create better digital experiences

If this header is present, its value is checked against the Origin header of request headers. If the values match, the request will be completed successfully and resources will be shared. Upon mismatch, the browser will respond with a CORS error.

To allow all origins to access the resources in the case of a public API, the Access-Control-Allow-Origin header can be set to * on the server. In order to restrict only particular origins to access the resources, the header can be set to the complete domain of the client origin such as https://mywebsite.com .

Access-Control-Allow-Methods

The Access-Control-Allow-Methods response header is used to specify the allowed HTTP method or a list of HTTP methods such as GET , POST , and PUT that the server can respond to.

This header is present in the response to pre-flighted requests. If the HTTP method of your request is not present in this list of allowed methods, it will result in a CORS error. This is highly useful when you want to restrict users from modifying the data through POST , PUT , PATCH , or DELETE requests.

Access-Control-Allow-Headers

The Access-Control-Allow-Headers response header indicates the list of allowed HTTP headers that your request can have. To support custom headers such as x-auth-token , you can set up CORS on your server accordingly.

Requests that consist of other headers apart from the allowed headers will result in a CORS error. Similar to the Access-Control-Allow-Methods header, this header is used in response to pre-flighted requests.

Access-Control-Max-Age

Pre-flighted requests require the browser to first make a request to the server using the OPTIONS HTTP method. Only after this can the main request be made if it is deemed safe. However, making the OPTIONS call for each pre-flighted request can be expensive.

To prevent this, the server can respond with the Access-Control-Max-Age header, allowing the browser to cache the result of pre-flighted requests for a certain amount of time. The value of this header is the amount of time in terms of delta seconds.

More great articles from LogRocket:

• Don't miss a moment with The Replay , a curated newsletter from LogRocket
• Learn how LogRocket's Galileo cuts through the noise to proactively resolve issues in your app
• Use React's useEffect to optimize your application's performance
• Switch between multiple versions of Node
• Discover how to use the React children prop with TypeScript
• Explore creating a custom mouse cursor with CSS
• Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Overall, here’s the syntax of how CORS response headers look like:

Simple requests vs. pre-flighted requests

Requests that do not trigger a CORS preflight fall under the category of simple requests. However, the request has to satisfy some conditions only after it is deemed as a simple request. These conditions are:

• The HTTP method of the request should be one of these: GET , POST , or HEAD
• The request headers should only consist of CORS safe-listed headers such as Accept , Accept-Language , Content-Language , and Content-Type apart from the headers automatically set by the user agent
• The Content-Type header should have only either of these three values: application/x-www-form-urlencoded , multipart/form-data , or text/plain
• No event listeners are registered on the object returned by the XMLHttpRequest.upload property if using XMLHttpRequest
• No ReadableStream object should be used in the request

On failing to satisfy either of these conditions, the request is considered to be a pre-flighted request. For such requests, the browser has to first send a request using the OPTIONS method to the different origin.

This is used to check if the actual request is safe to send to the server. The approval or rejection of the actual request depends on the response headers to the pre-flighted request. If there is a mismatch between these response headers and the main request’s headers, the request is not made.

Enabling CORS

Let’s consider our initial situation where we faced the CORS error. There are multiple ways we could resolve this issue depending on whether we have access to the server on which the resources are hosted. We can narrow it down to two situations:

• You have access to the backend or know the backend developer
• You can manage only the frontend and cannot access the backend server

If you have access to the backend:

Because CORS is just an HTTP header-based mechanism, you can configure the server to respond with appropriate headers in order to enable resource sharing across different origins. Have a look at the CORS headers we discussed above and set the headers accordingly.

For Node.js + Express.js developers, you can install the cors middleware from npm. Here is a snippet that uses the Express web framework, along with the CORS middleware:

If you don’t pass an object consisting of CORS configuration, the default configuration will be used, which is equivalent to:

Here is how you could configure CORS on your server which will only allow GET requests from https://yourwebsite.com with headers Content-Type and Authorization with a 10 minutes preflight cache time:

While this code is specific to Express.js and Node.js, the concept remains the same. Using the programming language and framework of your choice, you can manually set the CORS headers with your responses or create a custom middleware for the same.

If you only have access to the frontend:

Quite often, we may not have access to the backend server. For example, a public API. Due to this, we cannot add headers to the response we receive. However, we could use a proxy server that will add the CORS headers to the proxied request.

The cors-anywhere project is a Node.js reverse proxy that can allow us to do the same. The proxy server is available on https://cors-anywhere.herokuapp.com/ , but you can build your own proxy server by cloning the repository and deploying it on a free platform like Heroku or any other desired platform.

In this method, instead of directly making the request to the server like this:

Simply append the proxy server’s URL to the start of the API’s URL, like so:

As we learn to appreciate the same-origin policy for its security against cross-site forgery attacks, CORS does seem to make a lot of sense. While the occurrences of the red CORS error messages in the console aren’t going to magically disappear, you are now equipped with the knowledge to tackle these messages irrespective of whether you work on the frontend or the backend.

Get set up with LogRocket's modern error tracking in minutes:

• Visit https://logrocket.com/signup/ to get an app ID

Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not server-side

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)

Stop guessing about your digital experience with LogRocket

Recent posts:.

Mojo CSS vs. Tailwind: Choosing the best CSS framework

Compare the established Tailwind CSS framework with the newer Mojo CSS based on benchmarks like plugins, built-in components, and more.

Leader Spotlight: Riding the rocket ship of scale, with Justin Kitagawa

We sit down with Justin Kitagawa to learn more about his leadership style and approach for handling the complexities that come with scaling fast.

Nx adoption guide: Overview, examples, and alternatives

Let’s explore Nx features, use cases, alternatives, and more to help you assess whether it’s the right tool for your needs.

Understanding security in React Native applications

Explore the various security threats facing React Native mobile applications and how to mitigate them.

2 Replies to "The ultimate guide to enabling Cross-Origin Resource Sharing (CORS)"

In depth and finly captured.

I may have missed something but if we can kind of bypass the cors policy by just using cors-anywhere, what’s the point in using cors/setting up cors in the server anyway????

Leave a Reply Cancel reply

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free
• English (US)

Reason: CORS request did not succeed

What went wrong.

The HTTP request which makes use of CORS failed because the HTTP connection failed at either the network or protocol level. The error is not directly related to CORS, but is a fundamental network error of some kind.

In many cases, it is caused by a browser plugin (e.g. an ad blocker or privacy protector) blocking the request.

Other possible causes include:

• Trying to access an https resource that has an invalid certificate will cause this error.
• Trying to access an http resource from a page with an https origin will also cause this error.
• From Firefox 68 to Firefox 84, https pages were not permitted to access http://localhost . This has been changed with Bug 1488740 .
• The server did not respond to the actual request (even if it responded to the Preflight request ). One scenario might be an HTTP service being developed that panicked without returning any data.
• CORS errors
• Glossary: CORS
• CORS introduction

• skip navigation All Products Product Bundles DevCraft All Telerik .NET tools and Kendo UI JavaScript components in one package. Now enhanced with: NEW : Design Kits for Figma

All You Need to Know About CORS & CORS Errors

Do you understand CORS and why you get CORS errors? Let’s understand the basics behind this security practice and one of the most common errors you’ll see.

When we first start making our apps, we often make one mistake that can send us in the wrong direction. A “CORS error” message shows up when we try to get a resource from a different domain. We don’t know what to do or how to make this work. There are a lot of developers who know about the error but don’t know how it works or how to fix it.

Let’s get started and learn about one of the most common mistakes and why it’s such a big deal.

What is CORS?

CORS helps to ensure that only authorized domains can access sensitive data or resources, and that web applications are not vulnerable to cross-site scripting (XSS) attacks or other types of security vulnerabilities by allowing web developers to explicitly allow or block cross-origin requests. It also allows webpages to make explicit cross-origin requests for resources while preventing unauthorized access to other resources.

Before CORS, webpages could only make requests to the same domain that served the web page, a practice known as the “same-origin policy.” This policy was implemented to prevent malicious websites from sending unauthorized requests to other domains, which could expose sensitive data or compromise security.

However, as the web evolved and web applications became more complex, so did the requirement for webpages to be able to make requests to external domains. Web applications, for example, may need to access APIs or other data sources hosted on different domains, or they may need to include external domain resources such as images or stylesheets.

CORS was created to address this need while still maintaining web security. It allows web developers to specify which domains are allowed to access their resources, as well as control the types of requests that can be made and the types of data that can be returned.

What are CORS Errors?

CORS errors happen when a webpage makes a request to a different domain than the one that served the page, and the server responds with an HTTP error because the “Origin” header in the request is not allowed by the server’s CORS configuration.

The Reason for CORS

We discussed what a CORS error is and how it works, but to fully understand it, let’s use a simple analogy.

Consider that both you and your friend have websites. Your website represents one domain on the internet, while your friend’s website represents another. To keep your websites distinct and secure, there are regulations in place that restrict your website’s access to resources (such as photos or data) outside of your domain. This is similar to the “same-origin policy” in web browsers, which only permits webpages to access resources from the same domain from which the page was served.

Imagine that you wish to include an image from a friend’s website on your own. You wish you could use the image, but you cannot since it is private property and you lack permission to do so. This is analogous to a webpage attempting to access a resource from a domain other than the one that delivered the webpage but being unable to do so due to the same-origin policy.

To solve this issue, your friend could permit you to use the image under certain conditions. For instance, they may enable you to use the image if you first ask for approval and use it for a specific reason.

This is similar to CORS, which enables web developers to declare which domains are permitted to access their resources, as well as to regulate the types of requests that can be performed and the types of data returned. By permitting you to use the image as long as you adhere to the regulations, your friend can continue to enjoy the privacy of their property (the image) while enabling you to use it on your website.

How to Solve CORS Errors

There are several ways to solve CORS errors, depending on the cause of the error and the specific requirements of your application. Here are some common approaches:

Allow Cross-Origin Requests on Server

If the server is blocking the request because the server’s CORS configuration does not allow the “Origin” header, you can configure the server to allow the request by adding the domain of the web page that requested the list of allowed origins, or by setting the Access-Control-Allow-Origin header to “ * ” to allow any domain to access the resource.

The Access-Control-Allow-Origin header is an HTTP response header that is used in the case of CORS (Cross-Origin Resource Sharing). It specifies which domain is permitted to access the resource in the response.

When a webpage requests a different domain, the browser sends an HTTP request with an “Origin” header that indicates the domain of the webpage that made the request. Based on the value of the “Origin” header, the server can either allow or deny the request. If the server accepts the request, it sends an HTTP response with an Access-Control-Allow-Origin header indicating the domain that is permitted to access the resource.

For our previous example, our page “https://my-website.com” requests our friend’s page “https://my-friend.com”, the server at “https://my-friend.com” could send the following response:

This allows our “https://my-website.com” page to access the resource but prevents any other domain from doing so.

The Access-Control-Allow-Origin header can also be set to “ * ” to allow access to the resource from any domain. However, use with caution because it may expose sensitive data or resources to unauthorized domains.

Allow Some HTTP Methods

When updating your CORS configuration, you must use the “Access-Control-Allow-Methods” header in your server’s HTTP responses to allow the necessary HTTP methods. This header indicates which HTTP methods are permitted in cross-origin requests.

To allow the GET and POST methods, for example, include the following header in your server’s HTTP responses:

You can also use the “ * ” value to permit all HTTP methods, but this should be done with caution because it could expose your server to security vulnerabilities.

You may also need to update your server’s CORS configuration to allow the necessary HTTP headers in addition to specifying the allowed methods. This is accomplished through the use of the “Access-Control-Allow-Headers” header, which specifies which HTTP headers are permitted in cross-origin requests.

Overall, CORS is an important security feature that helps to ensure the safety and security of the web, and is essential for modern web applications that make cross-origin requests.

Leonardo Maldonado

Leonardo is a full-stack developer, working with everything React-related, and loves to write about React and GraphQL to help developers. He also created the 33 JavaScript Concepts.

Related Posts

How to secure your angular app, api security checklist: how to protect your apis, 11 api security best practices to secure your business, all articles.

• ASP.NET Core
• ASP.NET MVC
• ASP.NET AJAX
• Blazor Desktop/.NET MAUI
• Design Systems
• Document Processing
• Accessibility

Latest Stories in Your Inbox

Subscribe to be the first to get our expert-written articles and tutorials for developers!

All fields are required

Progress collects the Personal Information set out in our Privacy Policy and the Supplemental Privacy notice for residents of California and other US States and uses it for the purposes stated in that policy.

You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info

By submitting this form, I understand and acknowledge my data will be processed in accordance with Progress' Privacy Policy .

I agree to receive email communications from Progress Software or its Partners , containing information about Progress Software’s products. I understand I may opt out from marketing communication at any time here or through the opt out option placed in the e-mail communication received.

By submitting this form, you understand and agree that your personal data will be processed by Progress Software or its Partners as described in our Privacy Policy . You may opt out from marketing communication at any time here or through the opt out option placed in the e-mail communication sent by us or our Partners.

We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here .

Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here .

How to Debug Any CORS Error

Your request is hitting an error due to CORS. Not all is lost! Most CORS errors are quick & easy to debug and fix, once you understand the basics. Let's sort it out.

You know you're hitting a CORS error when you see error messages like:

Access to fetch at ' https://example.com ' from origin ' http://localhost:8000 ' has been blocked by CORS policy.

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

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://example.com/

Response to preflight request doesn't pass access control check

The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'

Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.

Request header field custom is not allowed by Access-Control-Allow-Headers in preflight response.

In each of these cases, you've asked JavaScript running in your page to send a request to a different origin, and at some stage the browser is refusing to do what you want.

What is CORS?

When you include JavaScript in a web page, you're running code on your user's computer, inside their browsing session.

That's a lot of power, and browsers are designed to protect users from the risks of this. CORS is one of these protections, aiming to protect the user and the services they use from two main attacks:

• CORS stops you from using the user's existing login session (their cookies and other cached authentication details) when communicating with other servers. JavaScript on your web page shouldn't be able to send requests to the Facebook API using their existing Facebook session. Without CORS, any web page could talk to other servers as you.
• CORS stops you from talking to servers that might only be accessible from their machine, but which aren't accessible publicly. Your web page should not be able to send requests to my-intranet-server.local , which might be an internal company server or your home router, and it should not be able to talk to servers that are listening only for localhost requests. Servers like these are often unauthenticated and very trusting, because they aren't connected to the public internet. Without CORS, any web page you visit could access them.

This only applies to cross origin requests, e.g. requests from https://example.com to https://google.com . The protocol, domain, and port all count as part of a URL's origin, but the path does not, so https://example.com/abc and https://example.com/def have the same origin, but http://localhost:123 and http://localhost:456 do not.

CORS protects against the above attacks by requiring the target server to opt into receiving dangerous requests from the source server, and to opt in to allowing pages from other origins to read responses. The Facebook API and your local network servers can accept requests from web pages running on other origins if they want to, but only if they agree.

Why doesn't my CORS work?

Your CORS request is failing because you're sending a request that the target server hasn't agreed to allow.

There's two classes of CORS request:

'Simple' cross-origin requests. There are basic requests that use no unsafe headers, don't stream requests or responses, and only use HEAD, GET or POST methods (with limited safe content types). Any request that's possible here would also be possible by e.g. loading an image or posting a form to the cross-origin request (and we can't stop those, for huge backwards compatibility reasons).

You can always send simple requests, but you might not be allowed to read the response.

'Preflighted' cross-origin requests. These are more complex requests, that aren't easy to send in other ways. A 'preflight' request will be sent to ask the server for permission before sending any of these requests, and if it's rejected, you won't be able to send the request at all.

If the preflight request is successful, the real request is sent, and the final response to that still has to follow the same rules as a 'simple' response for you to be allowed to read it.

When a request is preflighted, before sending the real request the browser sends an OPTIONS request with headers explaining the real request that it wants to send. It expects a response including headers that explicitly allow the real request.

There's three ways that this might hit an error:

• You're sending a simple request, which is sent immediately, but the headers on the response don't allow you to read it.
• You're sending a preflighted request, and the headers on the preflight response don't allow you to send the real request.
• You're sending a preflighted request, the preflight went OK and the request was sent, but the headers on the final response for the real request don't allow you to read it.

The browser error message should show you which is happening for you. You can know if your request is being preflighted by looking for an OPTIONS request that's sent immediately before it.

The rules for the final (after preflight, if applicable) response are:

• The response must include a Access-Control-Allow-Origin header, whose value either matches the page's origin or is * . The page's origin is sent in the request in an Origin header.
• If the request included credentials (e.g. fetch(url, { credentials: 'include' }) ) then the response headers must include Access-Control-Allow-Credentials: true , and the Access-Control-Allow-Origin header must match exactly (i.e. * is not allowed).

If the response doesn't follow those rules, then the server hasn't opted in to your request, and you won't be allowed to read the response.

If you're in cases 1 or 3, you must be breaking one of these rules.

The rules for the preflight request are:

• The preflight response must include a Access-Control-Allow-Origin header, whose value either matches the page's origin or is * . The page's origin is sent in the preflight request in an Origin header.
• If the page wants to send custom headers, then it will include Access-Control-Request-Headers listing the headers in the preflight OPTIONS request, and the server must include a Access-Control-Allow-Headers header that includes all those headers in the response. * can also be used here, but it won't match an Authorization header - that must always be listed explicitly.
• If the page wants to use a non-simple HTTP method, it will include Access-Control-Request-Method in the preflight OPTIONS request, and the server must include a Access-Control-Allow-Methods header that includes that method in the response.
• If the page wants to send credentials (e.g. fetch(url, { credentials: 'include' }) ) the response must include a Access-Control-Allow-Credentials: true header, and the Access-Control-Allow-Origin header must match exactly (i.e. * is not allowed).

If your preflight OPTIONS response doesn't follow these rules, then you won't be allowed to send the real request at all.

If you're in case 2, you must be breaking one of these rules.

It's also possible that you're in case 2, but you actually don't want to read the response - you just want to send it. To do that, you'll need to simplify your request such that it's a simple request. You can use { mode: 'no-cors' } on your fetch options to enforce this (but note that this doesn't change the rules, it just enforces that it's a simple request where you can't read the result).

How can I fix my CORS error?

To know exactly why your request is failing, you need to inspect the traffic itself, find where you're breaking the rules above, and then either:

• Change the request to make it a simple request
• Change the server's response to follow the rules above
• If all else fails, proxy the request through your own server on your own origin, so it's not a cross-origin request (proxying avoids the attacks above, because it doesn't let you use the cookies or authentication details from the user's browser, and it requires the target server to be accessible from your source server)

To inspect the traffic, you can use your browser built-in tools, but it's usually easier to use a dedicated HTTP debugger like HTTP Toolkit . Dedicated tools make it much easier to see the data, rather than (for example) Chrome's very cramped and fiddly network tab, and you can also breakpoint responses and edit the headers to test how the browser will handle changes without actually changing your server. Also, some Chrome versions don't show all CORS requests.

Hopefully, once you examine your CORS requests & responses, it's clear where you're breaking the rules above.

If not, try walking through Will It CORS . This is a self-explaining implementation of the CORS rules: you can input step by step what you're trying to do, and it'll tell you what will happen and why, and how you can change it.

There's also a few common mistakes that you should watch out for:

• Trying to request content from another origin that isn't explicitly available cross-origin. If its not your server, and it doesn't actively want CORS requests, you're not going to work around most issues: you need to proxy the request, ask the owner to allow it, or do something entirely different.
• Always returning * for Access-Control-Allow-Origin , and then trying to send credentials.
• Adding CORS headers for preflight OPTIONS requests, but forgetting to also include CORS headers on the final request too.
• Unnecessarily sending custom request headers. This will trigger a preflight request. You can often get by just using the CORS-safe request headers instead, or moving request data into the body of your request.
• Incorrectnyl caching CORS response headers independent of their origin, by not using Vary: Origin . If you do this then responses for requests from one origin may be cached and returned for later requests from a different origin. That mismatched data can quickly break things.
• Trying to access response headers without including an Access-Control-Expose-Headers header. In this case, all headers except the CORS-safe response headers will be unexpectedly undefined, even though they were sent by the server.
• Sending cross-origin mixed-content requests (a request from https://... to http://... ). These will always be blocked, regardless of the details, as insecure content like this is never allowed on HTTPS origins. There's not much you can do about this, other than changing to use HTTPS on both servers.

That covers the core of CORS, how it can go wrong, and how to fix it. Have more questions? Get in touch on Twitter .

No spam, just new blog posts hot off the press

CORS Errors

What is cors ​.

Cross-Origin Resource Sharing (CORS) is a mechanism that browsers and webviews — like the ones powering Capacitor and Cordova — use to restrict HTTP and HTTPS requests made from scripts to resources in a different origin for security reasons, mainly to protect your user's data and prevent attacks that would compromise your app.

In order to know if an external origin supports CORS, the server has to send some special headers for the browser to allow the requests.

An origin is the combination of the protocol , domain , and port from which your Ionic app or the external resource is served. For example, apps running in Capacitor have capacitor://localhost (iOS) or http://localhost (Android) as their origin.

When the origin where your app is served (e.g. http://localhost:8100 with ionic serve ) and the origin of the resource being requested (e.g. https://api.example.com ) don't match, the browser's Same Origin Policy takes effect and CORS is required for the request to be made.

CORS errors are common in web apps when a cross-origin request is made but the server doesn't return the required headers in the response (is not CORS-enabled):

XMLHttpRequest cannot load https://api.example.com . No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin ' http://localhost:8100 ' is therefore not allowed access.

How does CORS work ​

Request with preflight ​.

By default, when a web app tries to make a cross-origin request the browser sends a preflight request before the actual request. This preflight request is needed in order to know if the external resource supports CORS and if the actual request can be sent safely, since it may impact user data.

A preflight request is sent by the browser if:

• Accept-Language
• Content-Language
• Content-Type
• Viewport-Width
• application/x-www-form-urlencoded
• multipart/form-data
• Or if a ReadableStream or event listeners in XMLHttpRequestUpload are used.

If any of the conditions above are met, a preflight request with the OPTIONS method is sent to the resource URL.

Let's suppose we are making a POST request to a fictional JSON API at https://api.example.com with a Content-Type of application/json . The preflight request would be like this (some default headers omitted for clarity):

If the server is CORS enabled, it will parse the Access-Control-Request-* headers and understand that a POST request is trying to be made from http://localhost:8100 with a custom Content-Type .

The server will then respond to this preflight with which origins, methods, and headers are allowed by using the Access-Control-Allow-* headers:

If the returned origin and method don't match the ones from the actual request, or any of the headers used are not allowed, the request will be blocked by the browser and an error will be shown in the console. Otherwise, the request will be made after the preflight.

In our example, since the API expects JSON, all POST requests will have a Content-Type: application/json header and always be preflighted.

Simple requests ​

Some requests are always considered safe to send and don't need a preflight if they meet all of the following conditions:

• No ReadableStream or event listeners in XMLHttpRequestUpload are used.

In our example API, GET requests don't need to be preflighted because no JSON data is being sent, and so the app doesn't need to use the Content-Type: application/json header. They will always be simple requests.

CORS Headers ​

Server headers (response) ​, browser headers (request) ​.

The browser automatically sends the appropriate headers for CORS in every request to the server, including the preflight requests. Please note that the headers below are for reference only, and should not be set in your app code (the browser will ignore them).

All Requests ​

Preflight requests ​, solutions for cors errors ​, a. enabling cors in a server you control ​.

The correct and easiest solution is to enable CORS by returning the right response headers from the web server or backend and responding to preflight requests, as it allows to keep using XMLHttpRequest , fetch , or abstractions like HttpClient in Angular.

Ionic apps may be run from different origins, but only one origin can be specified in the Access-Control-Allow-Origin header. Therefore we recommend checking the value of the Origin header from the request and reflecting it in the Access-Control-Allow-Origin header in the response.

Please note that all of the Access-Control-Allow-* headers have to be sent from the server, and don't belong in your app code.

Here are some of the origins your Ionic app may be served from:

Capacitor ​

Replace localhost with your own hostname if you have changed the default in the Capacitor config.

Ionic WebView 3.x plugin on Cordova ​

Replace localhost with your own hostname if you have changed the default in the plugin config.

Ionic WebView 2.x plugin on Cordova ​

Replace port 8080 with your own if you have changed the default in the plugin config.

Local development in the browser ​

Port numbers can be higher if you are serving multiple apps at the same time.

Allowing any origin with Access-Control-Allow-Origin: * is guaranteed to work in all scenarios but may have security implications — like some CSRF attacks — depending on how the server controls access to resources and use sessions and cookies.

For more information on how to enable CORS in different web and app servers, please check enable-cors.org

CORS can be easily enabled in Express/Connect apps with the cors middleware:

B. Working around CORS in a server you can't control ​

Don't leak your keys ​.

If you are trying to connect to a 3rd-party API, first check in its documentation that is safe to use it directly from the app (client-side) and that it won't leak any secret/private keys or credentials, as it's easy to see them in clear text in Javascript code. Many APIs don't support CORS on purpose, in order to force developers to use them in the server and protect important information or keys.

1. Native-only apps (iOS/Android) ​

Capacitor applications (recommended) ​.

For Capacitor applications, use the Capacitor HTTP API . This API patches fetch and XMLHttpRequest to use native libraries. Please note that if you also deploy the application to a web-based context such as PWA or the local development server (via ionic serve for example) you still need to implement CORS for those scenarios.

Legacy Cordova Applications ​

For legacy Cordova applications, use the HTTP plugin with the Awesome Cordova Plugins wrapper . Please note that this plugin doesn't work in the browser, so the development and testing of the app must always be done in a device or simulator going forward.

2. Native + PWAs ​

Send the requests through an HTTP/HTTPS proxy that bypasses them to the external resources and adds the necessary CORS headers to the responses. This proxy must be trusted or under your control, as it will be intercepting most traffic made by the app.

Also, keep in mind that the browser or webview will not receive the original HTTPS certificates but the one being sent from the proxy if it's provided. URLs may need to be rewritten in your code in order to use the proxy.

Check cors-anywhere for a Node.js CORS proxy that can be deployed in your own server. Using free hosted CORS proxies in production is not recommended.

C. Disabling CORS or browser web security ​

Please be aware that CORS exists for a reason (security of user data and to prevent attacks against your app). It's not possible or advisable to try to disable CORS .

Older webviews like UIWebView on iOS don't enforce CORS but are deprecated and are very likely to disappear soon. Modern webviews like iOS WKWebView or Android WebView (both used by Capacitor) do enforce CORS and provide huge security and performance improvements.

If you are developing a PWA or testing in the browser, using the --disable-web-security flag in Google Chrome or an extension to disable CORS is a really bad idea. You will be exposed to all kind of attacks, you can't ask your users to take the risk, and your app won't work once in production.

CORS Errors in Ionic Apps

• What is CORS?
• Request with preflight
• Simple requests
• Server Headers (Response)
• Browser Headers (Request)
• A. Enabling CORS in a server you control
• B. Working around CORS in a server you can't control
• C. Disabling CORS or browser web security

Solving CORS Errors in React: A Step-by-Step Guide

by jovana | Nov 7, 2023

The Concept

How cors works, how to solve cors errors, what is cross-origin resource sharing (cors).

Cross-Origin Resource Sharing, commonly known as CORS , is a security feature implemented by web browsers. Its primary function is to control web page requests made by scripts running on one domain to another domain , a situation commonly known as cross-origin requests.

Imagine you’re browsing a website, and the web page you’re visiting is attempting to request resources, such as images, scripts, or fonts, from another domain. Without CORS, your browser might block these requests as a security measure. This is where CORS comes into play, facilitating secure interactions between websites hosted on different domains.

CORS operates through HTTP headers and their associated responses. It involves both the browser (the client-side) and the server. When a web page makes a cross-origin request, the server must include specific HTTP headers to inform the browser whether the request is allowed. These headers provide the necessary permissions for the browser to proceed with the request.

To solve CORS errors in a React application, you can follow this step-by-step guide:

Understand CORS Start by understanding what CORS is and why it’s needed. CORS is a security feature implemented by web browsers to prevent unauthorized access to resources on different domains. Browsers enforce same-origin policy, which restricts web pages from making requests to a different origin (domain) than the one that served the web page.

Check the Error :

When a CORS (Cross-Origin Resource Sharing) error occurs, checking the console in your browser’s developer tools is indeed a crucial step to diagnose the issue. By examining the error messages in the console, you can pinpoint the specific problem and understand the domains involved. CORS errors may manifest in various ways, and some of the possible error messages you might encounter include:

• Access-Control-Allow-Origin Error : This is one of the most common CORS errors. It occurs when the server doesn’t include the appropriate Access-Control-Allow-Origin header in the response, specifying which domains are permitted to access its resources.
• Invalid CORS Request : This error often appears when you attempt to make a request using an HTTP method other than GET or POST, or when you include custom headers in your request. Browsers will then initiate a preflight request, and if the server doesn’t handle it correctly, you’ll receive an error.
• Origin Not Allowed : If the origin making the request is not on the list of allowed origins specified by the server, you will encounter this error. The server must explicitly permit the origin for the request to proceed without errors.
• No ‘Access-Control-Allow-Credentials’ Header : When you’re dealing with requests that involve credentials and cookies, the server must include the Access-Control-Allow-Credentials header set to true in the response. If this header is missing or set to false , a CORS error will occur.
• Blocked by Content Security Policy (CSP) : If your website has a Content Security Policy (CSP) in place that restricts the loading of external resources, it can lead to CORS errors if not configured correctly. In such cases, you might see errors related to CSP violations in the console.
• Cross-Origin Request Blocked : This is a general error message that signifies the browser’s rejection of a cross-origin request due to CORS restrictions. It can occur for various reasons, including missing headers or invalid origins.
• Options Method Precondition Failed : In cases where preflight requests (triggered by more complex requests) are not correctly handled by the server, you may encounter this error. The server should respond to OPTIONS requests with the appropriate CORS headers.
• Network Error : Occasionally, CORS errors can result from network-related issues, such as server unavailability or timeouts. These errors may not always provide CORS-specific details, so troubleshooting network connectivity is also important.

Server Configuration

If you control the server, you’ll need to configure it to allow cross-origin requests. This is done by setting appropriate response headers on the server. The primary header to set is the Access-Control-Allow-Origin header, which specifies which domains are allowed to access the server. You can set it to * for allowing all domains or specify specific domains.

For example, in Express.js (Node.js), you can set the header like this:

Use Credentials

If your request involves cookies or authentication, you may need to set the withCredentials option to true on your client-side requests in React:

Preflight Requests

In some cases, your browser may send a preflight request (an HTTP OPTIONS request) to check if the server allows the actual request. Ensure that your server responds correctly to these preflight requests.

Handling Errors

In your React code, you should handle CORS errors gracefully. You can use try-catch blocks or .catch() with Promises to handle errors and provide feedback to users.

Proxy Server (Development)

In development, you can set up a proxy server to avoid CORS issues. If you’re using Create React App, you can add a proxy field to your package.json :

This way, requests from your React app during development will be routed through the proxy server to the specified domain.

Environment Variables

If you have different API URLs for development and production, consider using environment variables to manage the API endpoints. This allows you to switch between development and production servers easily.

By following these steps, you can effectively solve CORS errors in your React application and ensure that it can communicate with external servers or APIs without security restrictions.

Submit a Comment Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Submit Comment

Looking For Something?

Related articles.

useSyncExternalStore React API

You might have heard about a new tool called useSyncExternalStore() in React 18. It helps connect your React app to outside data sources. Usually, it's used by fancy internal tools like Redux to manage state. The official documentation explains that...

useActionState React Hook

The React team is updating a hook called useFormState because it caused confusion and wasn't just for forms. They're making these changes: Renaming it to useActionState. Adding a pending state to the returned values. Moving the hook from react-dom to the react...

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

You have Successfully Subscribed!

DEV Community

Posted on Mar 15, 2021 • Updated on Apr 30, 2021

React & REST API: How to overcome CORS errors

In Part 2 of this series, we'll be making a REST API call from our React project to a service that has some CORS policies implemented. In this particular example, we'll make REST API calls to xkcd's API.

Make REST API calls to xkcd

What is xkcd.

xkcd is a webcomic series created by American author Randall Munroe. You can find the awesome comics here .

xkcd has an API?

Yes, it does indeed have an API. You can find the great and concise API docs here .

What are we going to do?

We'll make REST API calls to one of my favorite comic strips that has an ID of 327, i.e. our endpoint will be https://xkcd.com/327/info.0.json . This will return JSON data about that particular comic strip.

Let's try calling it!

OK, so the implementation should be fairly simple. We made our REST API call to the Random User Generator API in our previous article - we just have to switch around the endpoint URL, right?

OK that was super easy! Now let's refresh our React page.

...? Access to fetch at blah blah from origin bleh bleh has been blocked by CORS policy .... say what now???

Well, it looks like the response didn't render. And there seems to be a whole lot of red text in the console..._(┐「ε:)_

That error we see in the console is well known as the CORS Error . Basically, resources that lie on xkcd's domain cannot be requested from another domain (i.e. our front-end React App).

There are several ways we can overcome this issue:

• Make REST API calls from the same domain as xkcd
• Edit the CORS settings of xkcd's server
• Make REST API calls from our own backend server

We can quickly experience method 1 if we navigate to any page on xkcd, and run the following code in the console.

The REST API request is being made on the same domain, so we don't run into any CORS errors. But it's highly unlikely that xkcd will host our React App on their site for us, so this isn't a realistic approach.

Method 2 again is unrealistic, since we don't have permission to access the settings of xkcd's server ¯\ (ツ) /¯

Method 3 is achievable by either setting up your own server and making requests from it, or using a services such as Zapier or Power Automate to make the requests for us.

In this article, we'll proceed with Method 3 by setting up a backend server using Express, which will act as a proxy to make REST API calls to xkcd.

Set up Express

What is express.

Express is a back-end web application framework for Node.

How will we use Express?

In this article, we'll treat Express as a tool for creating custom endpoints that our front-end React App can make calls to. When we make requests to these custom endpoints, the Express server will make REST API calls to our desired 3rd party service endpoint, receive the response, and then route the response back to our React App.

If that was a bit hard to grasp, think of it like ordering food at a nice restaurant. If we (front-end App) go directly to the kitchen and order food directly to the chef (3rd party service) , we'll be scolded for bad manners (CORS errors) . What we need to do is order food to the server (Express App) . The server (Express App) will take our order, walk to the kitchen, and request for the food to the chef (3rd party service) . After some time, the chef (3rd party service) will respond by giving the server (Express App) back a plate of food. The server (Express App) then carries the plate back to the table so that we (front-end App) can consume it.

OK, so let's go ahead to set up Express. This is basically a new node project with the Express dependencies installed. We'll want this project to be in a separate location from our React App, so let's navigate back up to our myproject directory, create a new directory called backend , and navigate into it. Since the terminal we were using is running the React app, go ahead to use the commands in a new terminal window.

From here we'll follow the Express installation tutorial to make our Express project.

You'll be asked a number of questions but you can skip through them by hitting enter until it's finished.

Continue to install some dependencies.

Finally, create a JavaScript file to work on - we'll call ours server.js .

Set up the Express code

We'll use this code for server.js

So, let's go through the code.

We first set our port to 5000, as we need it to be separate from the port we use on our front-end React App, which was defaulted to port 3000.

Express commonly uses routing that defines how the server's endpoints will respond to our front-end React App's requests. In this case, we've defined how the server will react when the endpoint http://localhost:5000/getData is accessed with a GET request.

But by default, our Express server will return CORS errors if accessed from our front-end React App that lies on a different domain (port). By setting up some CORS options, we allow requests from port 3000 to access our resources that lie on http://localhost:5000/getData .

If we were to access http://localhost:5000/getData with a GET request from our React App, Express will run the related function, which in this case would be a fetch request to the xkcd REST API endpoint. As this request is made from the server side, it does not run in to any CORS errors. The response from xkcd is obtained, and returned back to our React App through the res.json() method.

OK, now that's ready, let's start running the express server!

We can quickly see if it's running successfully by accessing http://localhost:5000/getData through the browser. We should see the JSON response being displayed.

OK, so it looks like the Express App is making successful REST API calls to https://xkcd.com/327/info.0.json . Note that if we want to make any changes to server.js , we should restart the App to see the changes take place.

Let's leave the Express server running, and return back to our React code so that it points to the Express App rather than directly to the xkcd server.

Update the React code

There isn't much to do here, except for updating our REST endpoint to our Express server instead of the xkcd endpoint.

Refresh the browser, and let's see if we've managed to bypass the CORS error.

Great! The REST API response has successfully rendered onto our HTML, and there are no CORS errors in our console.

And with that, we've managed to successfully avoid CORS errors to make REST API calls to xkcd by using our Express server as a proxy!

In the next part of the series, we'll make a REST API call to a Web Database service, Kintone, which will challenge us to our next issue.

Top comments (2)

Templates let you quickly answer FAQs or store snippets for re-use.

• Joined Oct 4, 2019

• Location Japan
• Work Kintone Developer Advocate at Cybozu
• Joined Oct 14, 2019

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

How to Add JSON-LD Structured Data to a Next.js Website

Sh Raj - Mar 23

Native App Killer? Why Progressive Web Apps Should Be Your Next Move

Mohamed Jubair - Mar 14

NAT traversal: How does it work?

alakkadshaw - Feb 29

Episode 24/11: Angular 17.3

ng-news - Mar 23

We're a place where coders share, stay up-to-date and grow their careers.

Failed to load resource: the server responded with a status of 401 () Error .

Hey guys I am working on a react project with appwrite backend services on a blog website, but I am constantly receiveing the error " Failed to load resource: the server responded with a status of 401 ()" , I also tried configuring cors , in the platforms section in appwrite but still I am getting the same error, can anyone please help me solve this problem , just let me know if you need any more details to solve the error .

Reply to this thread by joining our Discord

Recommended threads

Trying to create a google OAuth for a nextjs app, the method call looks like this: ```onClick={() => { account.createOAuth2Session("google", "http:...

I have a collection, for which I modified some attributes yesterday (>12h ago): I deleted some, added a few and modified one. I was able to fill the new attribu...

I followed a previous post on this topic (https://discord.com/channels/564160730845151244/1183890946493010051) and I get this recurring error. `An internal curl...

Need support?

Join our discord.

Get community support by joining our Discord server.

Get premium support

Join Appwrite Pro and get email support from our team.