What Is a CORS Error? Causes and How to Fix It

22 min read

What Is a CORS Error?

A CORS error explained in simple terms is a browser security error that occurs when a web page tries to access resources from a different origin, but the destination server does not provide the required permission through specific HTTP headers. CORS stands for Cross-Origin Resource Sharing, a browser security mechanism that allows servers to specify which websites can access their resources. Understanding CORS is essential for frontend and backend developers working with JavaScript, React, Next.js, Node.js, Express, and REST APIs.

For example, imagine your frontend application runs on http://localhost:3000, while your backend API runs on http://localhost:5000. When your frontend sends a request to the backend, the browser may block your JavaScript code from accessing the response if the server does not include the appropriate CORS headers.

Although the request might reach the server, the browser can still prevent your application from reading the response. This is why CORS errors frequently appear during API integration and local development.

In this guide, you will learn what CORS is, how CORS works, why CORS errors occur, how to fix common configuration problems, and how to implement secure cross-origin access in real-world applications.

What Is CORS (Cross-Origin Resource Sharing)?

CORS, or Cross-Origin Resource Sharing, is a browser-enforced security mechanism that controls whether JavaScript running on one origin can access resources from another origin.

An origin consists of three components:

• Scheme: The protocol, such as HTTP or HTTPS.
• Host: The domain name or IP address.
• Port: The network port used by the application.

For example, https://example.com and https://api.example.com are different origins because their hostnames differ. Similarly, http://localhost:3000 and http://localhost:5000 are different origins because their ports differ.

Understanding the Same-Origin Policy

The same-origin policy is a fundamental browser security rule that restricts how documents and scripts from one origin interact with resources belonging to another origin.

Without this protection, a malicious website could potentially use a visitor’s authenticated browser session to interact with another website and expose sensitive information.

CORS provides a controlled mechanism for servers to grant cross-origin access when appropriate.

How CORS Works

When a browser sends a cross-origin HTTP request, it evaluates the server’s response headers to determine whether the requesting origin is allowed to access the response.

The process generally works as follows:

1. A user opens a frontend website.
2. JavaScript sends a request to an API hosted on another origin.
3. The browser includes an Origin header when appropriate.
4. The server processes the request and returns an HTTP response.
5. The server includes the relevant CORS response headers.
6. The browser checks those headers against the request’s origin and requirements.
7. If the CORS checks pass, JavaScript can access the response; otherwise, the browser blocks access to it.

CORS is primarily enforced by browsers. Tools such as Postman, command-line HTTP clients, and server-to-server requests do not ordinarily enforce browser CORS restrictions.

Understanding CORS HTTP Headers

CORS depends on HTTP headers exchanged between the browser and server. Understanding these headers makes debugging much easier.

Access-Control-Allow-Origin

The Access-Control-Allow-Origin header identifies which origin is permitted to access a resource.

For example:

Access-Control-Allow-Origin: https://ccodelearner.com

This response allows browser requests from https://ccodelearner.com, subject to the other applicable CORS checks.

A server can also return:

Access-Control-Allow-Origin: *

The wildcard permits access from any origin for requests where wildcard access is appropriate. However, it cannot be used to authorize credentialed browser access involving cookies or HTTP authentication credentials.

Access-Control-Allow-Methods

The Access-Control-Allow-Methods header identifies which HTTP methods are permitted for cross-origin requests.

For example:

Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS

This header is especially relevant when the browser sends a preflight request to check whether a method is permitted.

Access-Control-Allow-Headers

The Access-Control-Allow-Headers header identifies which request headers the server permits JavaScript to use in a cross-origin request, particularly headers requested during preflight.

Example:

Access-Control-Allow-Headers: Content-Type, Authorization

If the browser requests permission to send a custom header that the server does not allow, the preflight check may fail.

Access-Control-Allow-Credentials

The Access-Control-Allow-Credentials header indicates whether a cross-origin response may be exposed to a browser request that uses credentials.

Example:

Access-Control-Allow-Credentials: true

When credentialed requests are used, the server must also return a specific allowed origin instead of *.

Access-Control-Expose-Headers

By default, JavaScript can read only a defined set of response headers. The Access-Control-Expose-Headers header makes additional response headers available to frontend code.

For example:

Access-Control-Expose-Headers: X-Total-Count, X-Request-Id

Without this header, JavaScript may be unable to read those custom response headers even when the CORS request itself succeeds.

Access-Control-Max-Age

The Access-Control-Max-Age header specifies how long the browser may cache the results of a successful preflight request, subject to browser-imposed limits.

Example:

Access-Control-Max-Age: 600

This tells the browser that the preflight permission can be cached for up to 600 seconds, subject to its implementation limits.

The Origin Header

The Origin header identifies the origin that initiated a cross-origin request.

For example:

Origin: https://ccodelearner.com

The backend can use this value when deciding whether to grant access. When implementing dynamic origin allowlists, validate the supplied origin against a trusted list rather than reflecting arbitrary origins into the response.

What Is a Preflight Request?

A preflight request is an HTTP request that a browser sends before certain cross-origin requests to determine whether the actual request is permitted.

It usually uses the OPTIONS method and asks the server which methods and headers it supports for the requested cross-origin operation.

Example of an OPTIONS Request

Suppose a frontend wants to send a JSON request using the PUT method. The browser might send:

OPTIONS /api/users/123 HTTP/1.1
Host: api.example.com
Origin: https://ccodelearner.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type, authorization

The server may respond:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://ccodelearner.com
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

If the response satisfies the browser’s requirements, the browser can proceed with the actual request.

A failed preflight request can prevent the browser from sending that actual request. Common reasons include a rejected origin, an unsupported method, missing allowed headers, an unsuccessful HTTP response, or middleware that does not handle OPTIONS requests correctly.

What Are Simple Requests?

Simple requests are cross-origin requests that meet specific conditions defined by the Fetch standard and do not require a preflight check.

Typical examples include certain GET and POST requests using permitted headers and content types. A request using Content-Type: application/json, for instance, generally does not qualify as a simple request because that content type is not among the permitted safelisted content types.

Simple requests are not exempt from CORS. The browser still checks the response before exposing it to JavaScript.

What Are Credentialed Requests?

Credentialed requests include browser credentials such as cookies or HTTP authentication information. Depending on the request, credentials may also include client certificates at the relevant protocol level.

For example, a frontend may use:

fetch("https://api.example.com/profile", {
  credentials: "include"
});

The server must explicitly allow the frontend origin and return Access-Control-Allow-Credentials: true when the response is intended to be exposed to this credentialed request.

Cookie policies, SameSite attributes, and third-party cookie restrictions can impose additional limitations even when CORS is configured correctly.

CORS vs Same-Origin Policy, CORS vs CSP, and CORS vs CSRF

Several web security concepts are related to CORS but solve different problems.

CORS vs Same-Origin Policy

The same-origin policy is the underlying browser security principle that restricts cross-origin interactions. CORS defines a mechanism through which servers can relax certain restrictions and permit controlled cross-origin access.

In short, the same-origin policy establishes the default boundary, while CORS allows servers to authorize particular cross-origin requests.

CORS vs CSP

Content Security Policy (CSP) helps website owners control which sources their pages may load or connect to. For example, the connect-src directive can restrict the API endpoints to which JavaScript may connect.

CORS, by contrast, determines whether a browser permits JavaScript to access a cross-origin response based on the server’s permissions.

A request can be blocked by CSP even when the destination server permits CORS. Both policies may need to be configured correctly.

CORS vs CSRF

Cross-Site Request Forgery (CSRF) is an attack in which an attacker attempts to make a user’s browser perform an unwanted action on a site where the user is authenticated.

CORS is not a complete CSRF defense. Some cross-origin requests can reach a server even when the attacking website cannot read the response. Applications that rely on cookies for authentication should use appropriate CSRF protections, such as anti-CSRF tokens, suitable SameSite cookie settings, and origin validation where applicable.

Common CORS Error Causes

A CORS policy error can result from multiple configuration or request-handling problems. Identifying the exact cause is the first step toward a reliable solution.

Missing Access-Control-Allow-Origin Header

A frequent error occurs when the server does not return the Access-Control-Allow-Origin header for a cross-origin response.

The API may return a valid JSON object, but the browser refuses to expose that response to frontend JavaScript because the required permission is missing.

Check the actual response headers and ensure the backend or appropriate gateway adds the correct header.

Wildcard Origin Error

A wildcard origin error can occur when a server uses:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

This combination does not authorize credentialed browser access. The server must specify an explicit allowed origin instead of using the wildcard.

Credentials With Wildcard Origin

When using fetch with credentials: "include" or Axios with withCredentials: true, the server must return a specific origin and permit credentials.

For example:

Access-Control-Allow-Origin: https://ccodelearner.com
Access-Control-Allow-Credentials: true

Do not use unrestricted origin reflection simply to eliminate an error. That approach can expose authenticated responses to untrusted websites.

Failed Preflight Request

A failed preflight request often occurs because the server does not handle OPTIONS requests correctly or does not allow the requested method or headers.

For example, an API may permit GET but reject DELETE, or it may allow Content-Type but omit Authorization from its permitted headers.

Redirects and Authentication Errors

A preflight request that encounters a redirect or an authentication failure may also fail. Login redirects, HTTP-to-HTTPS redirects, reverse proxy rules, and authorization middleware can all interfere with preflight processing.

Check the browser’s network panel to determine whether the failing response originates from the application server, authentication service, proxy, or gateway.

Other CORS Error Causes

Additional causes include:

• A backend exception that produces an error response without CORS headers.
• A development server using a different port from the API.
• A CDN or cache serving responses with incorrect origin-specific headers.
• Multiple layers adding conflicting Access-Control-Allow-Origin headers.
• A server permitting the wrong origin, scheme, or port.
• An API gateway failing to handle OPTIONS.
• A network error that prevents the browser from receiving a valid response.

How to Fix CORS Errors

The most reliable way to resolve a CORS error is to identify the failed request and configure the server that controls the requested resource.

Step 1: Inspect the Browser Console

Open Chrome DevTools, select the Console tab, and reproduce the request. Read the complete CORS error message.

Look for clues such as a missing Access-Control-Allow-Origin header, a rejected method, a disallowed request header, or a credential-related restriction.

Step 2: Inspect the Network Panel

Open the Network tab and select the failed request. Examine the request URL, request method, Origin header, status code, response headers, and any preceding OPTIONS request.

If the preflight request fails, focus on its response before troubleshooting the actual API operation.

Step 3: Configure the Backend

The backend should return the correct CORS response headers for permitted origins, methods, and request headers.

Do not assume that changing frontend JavaScript alone will fix a server-side CORS policy error.

Step 4: Verify Error Responses

Make sure the relevant server middleware applies CORS headers consistently to successful responses and appropriate error responses. Otherwise, a 401, 403, or 500 response may appear to be a CORS problem when the underlying issue is authentication, authorization, or a backend failure.

For more information about authentication and authorization status codes, read the CCodeLearner guide to HTTP 401 vs 403.

Step 5: Retest the Request

After changing the configuration, reload the application and repeat the request. Confirm that the preflight succeeds when required and that the actual response contains the expected headers.

Remember that cached preflight permissions may temporarily affect testing.

CORS Error in JavaScript and Fetch API

A CORS error in JavaScript often appears when the browser’s Fetch API tries to access a resource on another origin.

Example:

async function getUsers() {
  try {
    const response = await fetch(
      "https://api.example.com/users"
    );

    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }

    const users = await response.json();
    console.log(users);
  } catch (error) {
    console.error("Request failed:", error);
  }
}

getUsers();

This code handles request failures but does not bypass CORS. If the browser blocks access to the response, JavaScript generally receives a network-style failure rather than a readable HTTP response containing the server’s status and body.

The correct solution is to configure the API’s CORS policy, use an authorized same-origin proxy where appropriate, or access the resource through a supported server-side integration.

CORS Error in Axios

Axios is an HTTP client library commonly used in browser applications. However, using Axios instead of fetch does not bypass browser CORS enforcement.

Example:

import axios from "axios";

async function getUsers() {
  try {
    const response = await axios.get(
      "https://api.example.com/users"
    );

    console.log(response.data);
  } catch (error) {
    console.error("API request failed:", error.message);
  }
}

getUsers();

For cookie-based authentication, Axios supports withCredentials:

axios.get("https://api.example.com/profile", {
  withCredentials: true
});

Use this option only when cross-origin credentials are required and the server is configured to authorize the specific frontend origin. Axios cannot override a browser’s CORS policy.

CORS Error in React

A CORS error in React usually originates from the API or server configuration rather than React itself.

For example, a component may request data from a remote API when it mounts:

import { useEffect, useState } from "react";

export default function Users() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch("https://api.example.com/users")
      .then((response) => {
        if (!response.ok) {
          throw new Error("Unable to fetch users");
        }

        return response.json();
      })
      .then(setUsers)
      .catch((error) => {
        console.error(error);
      });
  }, []);

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

If this request fails because of CORS, inspect the API response and update its CORS configuration. React state management, hooks, and component structure do not change browser security rules.

CORS Error in Next.js

Next.js applications can make requests from both the browser and the server, and this distinction matters when troubleshooting CORS.

Browser-Side Requests

When a Client Component calls an external API from the browser, normal browser CORS rules apply. The external API must authorize the frontend origin.

Server-Side Requests

When a Next.js Server Component or server-side handler makes a request directly to another server, browser CORS enforcement does not apply to that server-to-server request.

A common solution is to create a Next.js Route Handler that fetches data from an external service and returns the required information to the frontend. The browser then communicates with the same-origin Next.js endpoint.

However, server-side requests must still enforce authentication, authorization, input validation, and appropriate protections against server-side request forgery (SSRF). A proxy should not become an unrestricted gateway to arbitrary URLs.

CORS Error in Node.js and Express

In Node.js and Express, CORS can be configured using middleware. The following example demonstrates how to permit a trusted frontend origin.

First, install the package:

npm install cors

Then configure Express:

const express = require("express");
const cors = require("cors");

const app = express();

app.use(cors({
  origin: "https://ccodelearner.com",
  methods: ["GET", "POST", "PUT", "DELETE"],
  allowedHeaders: ["Content-Type", "Authorization"]
}));

app.use(express.json());

app.get("/api/users", (req, res) => {
  res.json([
    { id: 1, name: "Alex" },
    { id: 2, name: "Sam" }
  ]);
});

app.listen(5000, () => {
  console.log("Server running on port 5000");
});

The middleware adds the relevant CORS headers and can handle preflight requests for configured routes.

For credentialed requests, use an explicit trusted origin and enable credentials:

app.use(cors({
  origin: "https://ccodelearner.com",
  credentials: true
}));

Do not combine credentialed access with a wildcard origin. In production, make sure the allowed origin matches the actual frontend domain and that other security controls remain in place.

CORS Error in REST APIs

REST APIs often serve multiple frontend applications, mobile clients, and third-party integrations. Their CORS policies should reflect the intended access requirements of browser-based clients.

For example, a public API may permit read-only access from any origin, while an administrative API may allow only a specific company dashboard.

A REST API should define:

• Allowed origins.
• Permitted HTTP methods.
• Allowed request headers.
• Credential requirements.
• Preflight response behavior.
• Appropriate handling of errors and redirects.

CORS is not an API authentication mechanism. An origin permitted by CORS is not automatically a trusted user, and non-browser clients can make requests without obeying browser CORS restrictions.

CORS Error in Localhost and Production

CORS errors frequently appear during development because frontend and backend servers run on separate ports.

For example:

• Frontend: http://localhost:3000
• Backend: http://localhost:5000

These URLs have different origins. Configure the backend to permit the exact development origin.

Be careful not to confuse localhost with 127.0.0.1, or HTTP with HTTPS. They may represent different origins even when they reach the same computer.

CORS Error in Production

Production errors can result from a domain change, HTTPS configuration, a CDN, an API gateway, or a deployment environment that uses different settings from development.

Maintain separate, intentional origin allowlists for development, staging, and production. Avoid allowing development domains in production unless there is a specific, justified need.

CORS Configuration for Nginx, Reverse Proxies, and API Gateways

CORS headers may be added by an application server, a reverse proxy, a CDN, or an API gateway. If multiple layers attempt to manage the same headers, they can produce conflicting responses.

Reverse Proxy CORS Fix

A reverse proxy CORS fix may involve correcting upstream response headers, ensuring OPTIONS requests reach the appropriate handler, and removing duplicate CORS headers.

Choose one clearly defined layer to manage the policy wherever practical. If the application already supplies CORS headers, avoid adding a conflicting second Access-Control-Allow-Origin header at the proxy.

Nginx CORS Configuration

Nginx can manage CORS headers, but configuration depends on the deployment architecture and the origin policy. A simplified example for a trusted origin might look like this:

location /api/ {
    add_header Access-Control-Allow-Origin
        "https://ccodelearner.com" always;

    add_header Access-Control-Allow-Methods
        "GET, POST, PUT, DELETE, OPTIONS" always;

    add_header Access-Control-Allow-Headers
        "Content-Type, Authorization" always;

    if ($request_method = OPTIONS) {
        return 204;
    }

    proxy_pass http://backend;
}

This is an illustrative starting point, not a complete production-ready configuration. It does not implement a dynamic origin allowlist or credentialed access, and add_header inheritance and error handling require careful testing. Ensure that the backend does not add duplicate headers and that preflight responses include all required permissions.

API Gateway CORS Settings

An API gateway may need explicit configuration for allowed origins, methods, headers, and preflight requests. Check whether CORS settings apply to both successful responses and gateway-generated errors.

If a gateway handles OPTIONS requests directly, make sure its configuration matches the methods and headers expected by the backend API.

How to Test CORS Headers

Testing CORS headers helps identify whether the problem comes from the frontend, API, proxy, or gateway.

Test With cURL

You can inspect a server’s response using:

curl -i \
  -H "Origin: https://ccodelearner.com" \
  https://api.example.com/users

For a preflight request, use:

curl -i -X OPTIONS \
  -H "Origin: https://ccodelearner.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: content-type,authorization" \
  https://api.example.com/users

Review the response status and CORS headers. These commands help inspect server behavior but do not reproduce every browser CORS enforcement rule.

Use Chrome DevTools

Open Chrome DevTools, navigate to the Network tab, and reproduce the error. Inspect both the OPTIONS request and the actual request, when present.

Check the Origin header, Access-Control-Allow-Origin, allowed methods, allowed headers, credential settings, response status, and redirect chain.

CORS Debugging Steps and Troubleshooting Checklist

Use this CORS troubleshooting checklist whenever a cross-origin request fails.

• Confirm that the frontend and API have different origins.

• Inspect the complete error in Chrome DevTools.

• Identify whether the actual request or preflight request failed.

• Verify the Origin header and exact origin configured on the server.

• Check for a missing Access-Control-Allow-Origin header.

• Confirm that the requested method appears in Access-Control-Allow-Methods.

• Verify that requested custom headers are permitted.

• Check whether credentialed requests require an explicit origin.

• Inspect redirects, authentication failures, and server errors.

• Check for duplicate or conflicting headers from proxies and gateways.

• Retest after configuration changes.

• Confirm that the solution works in the browser, not only in Postman or cURL.

CORS Best Practices and Security Risks

Correct CORS configuration should balance application functionality with browser security.

Use Explicit Origin Allowlisting

Dynamic origin allowlists are useful when an application supports several trusted frontend domains. Compare the incoming origin against a predefined list and return it only when it is authorized.

Do not reflect every incoming origin without validation. Doing so can expose sensitive responses if the application also permits credentials.

Avoid Unnecessary Wildcard Permissions

A wildcard may be suitable for certain public, non-credentialed resources. However, avoid it when a resource requires restricted origin access.

Treat CORS Separately From Authentication

CORS does not replace login requirements, access controls, CSRF defenses, or server-side authorization. Protect sensitive API operations independently of the browser’s origin policy.

Handle Errors Consistently

Ensure that your intended CORS policy applies consistently to relevant application responses. At the same time, avoid revealing sensitive server details in error messages.

Review Configuration After Deployment

Development, staging, and production often have different domains. Review origin allowlists whenever a frontend domain, API hostname, reverse proxy, or deployment environment changes.

Common CORS Mistakes

Developers frequently make the following mistakes while trying to fix cross-origin requests:

1. Adding headers only in frontend JavaScript: Browser CORS permissions must come from the server or another appropriately configured response-producing layer.
2. Using a wildcard with credentials: Credentialed browser access requires an explicit allowed origin.
3. Ignoring preflight requests: A failed OPTIONS request can stop the actual request from being sent.
4. Allowing the wrong port: Different ports represent different origins.
5. Disabling browser security: This does not solve the underlying server configuration issue and can expose the browser to risk.
6. Assuming Postman proves CORS works: Postman does not enforce browser CORS rules.
7. Using unrestricted development proxies in production: An open proxy can introduce security and abuse risks.
8. Ignoring caching and duplicate headers: Cached responses and multiple header-producing layers can make an apparently correct configuration fail.

Frequently Asked Questions About CORS

Conclusion

CORS is an important part of modern browser security that enables controlled cross-origin communication between frontend applications and APIs. Understanding the same-origin policy, preflight requests, HTTP headers, credentialed requests, and common configuration mistakes makes it easier to diagnose problems in JavaScript, React, Next.js, Node.js, Express, and REST APIs.

The most effective solution is usually to configure the server to allow the correct origins, methods, and headers while keeping authentication and authorization separate. Use Chrome DevTools, cURL, and a systematic troubleshooting checklist to identify the root cause rather than disabling browser security or adding unrestricted permissions.

For more programming guides and practical debugging tutorials, explore CCodeLearner and continue building your understanding of web development, HTTP status codes, and API security.