How to Fix Common CORS Errors: A Developer's Guide

A CORS error occurs when a browser blocks a cross-origin HTTP request because the server's response lacks the required Access-Control-Allow-Origin header. This security mechanism prevents unauthorized cross-domain data access. If you need to quickly generate the correct CORS headers for your server, the CORS Header Generator creates properly configured headers locally in your browser — no server configuration details are transmitted.

What Is CORS and Why Does It Exist?

CORS (Cross-Origin Resource Sharing) is a browser security feature built on top of the Same-Origin Policy. The Same-Origin Policy prevents a web page from making requests to a different domain, port, or protocol than the one that served the page. This stops malicious websites from reading your data from other sites you're logged into.

CORS relaxes this restriction in a controlled way. It lets servers declare which origins are allowed to access their resources using specific HTTP response headers. Without these headers, the browser blocks the response — even if the server successfully processed the request.

This is important to understand: CORS errors are browser-enforced, not server-enforced. The server receives the request, processes it, and sends a response. The browser then checks the response headers and decides whether to give the response to your JavaScript code or block it.

The Most Common CORS Errors

These are the errors you'll encounter most frequently in the browser console:

1. Missing Access-Control-Allow-Origin header

Access to fetch at 'https://api.example.com/data' from origin
'https://app.example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the
requested resource.

Fix: Add Access-Control-Allow-Origin: https://app.example.com to your server's response headers.

2. Preflight request failure

Access to fetch at 'https://api.example.com/data' from origin
'https://app.example.com' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check.

Fix: Your server must handle OPTIONS requests and return the required CORS headers (see the Preflight section below).

3. Wildcard with credentials

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

Fix: Replace * with the specific origin. When using credentials: 'include' in fetch, you must specify the exact origin and set Access-Control-Allow-Credentials: true.

Understanding Preflight Requests

Browsers send a preflight OPTIONS request before the actual request when any of these conditions are met:

• The HTTP method is anything other than GET, HEAD, or POST
• Custom headers are included (like Authorization or X-Custom-Header)
• The Content-Type is something other than application/x-www-form-urlencoded, multipart/form-data, or text/plain

The preflight asks the server: "Will you accept a PUT request with an Authorization header from https://app.example.com?" The server responds with headers indicating what is allowed. Only if the preflight passes does the browser send the actual request.

Fixing CORS in Popular Frameworks

Express.js (Node.js)

const cors = require('cors');

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

Flask (Python)

from flask_cors import CORS

CORS(app, origins=["https://app.example.com"],
     methods=["GET", "POST", "PUT", "DELETE"],
     allow_headers=["Content-Type", "Authorization"],
     supports_credentials=True)

Spring Boot (Java)

@CrossOrigin(
  origins = "https://app.example.com",
  methods = {GET, POST, PUT, DELETE},
  allowedHeaders = {"Content-Type", "Authorization"},
  allowCredentials = "true"
)
@RestController
public class ApiController { ... }

Nginx

location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
    add_header 'Access-Control-Allow-Credentials' 'true' always;

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Max-Age' 86400;
        add_header 'Content-Length' 0;
        return 204;
    }
}

CORS Headers Reference

Here are the CORS response headers and what they control:

• Access-Control-Allow-Origin — which origins can access the resource. Use a specific origin or * for public APIs (never with credentials).
• Access-Control-Allow-Methods — which HTTP methods are permitted (GET, POST, PUT, DELETE, etc.).
• Access-Control-Allow-Headers — which request headers the client is allowed to send.
• Access-Control-Allow-Credentials — whether cookies and auth headers should be included. Must be true for authenticated requests.
• Access-Control-Max-Age — how long (in seconds) the browser should cache preflight results. 86400 (24 hours) is common.
• Access-Control-Expose-Headers — which response headers JavaScript can read. By default, only a few "safe" headers are exposed.

Generate CORS Headers Instantly

Manually assembling the correct combination of CORS headers is error-prone — especially when dealing with credentials, preflight caching, and multiple allowed origins. The CORS Header Generator on ZeroData Tools lets you configure your allowed origins, methods, and headers through a visual interface and generates the correct server-side configuration instantly.

Everything runs locally in your browser. Your server configuration, domain names, and internal API routes are never transmitted to any external service.

Frequently Asked Questions

Why does CORS only affect browsers?

CORS is enforced by browsers as part of the Same-Origin Policy. Server-to-server requests (like those from cURL, Postman, or backend services) don't go through a browser, so they are not subject to CORS restrictions.

What is a preflight request?

A preflight request is an OPTIONS request that the browser automatically sends before certain cross-origin requests. It asks the server whether the actual request (with specific methods, headers, or credentials) is permitted. The server responds with CORS headers indicating what is allowed.

Can I use Access-Control-Allow-Origin: * with credentials?

No. The CORS specification explicitly forbids using the wildcard * for Access-Control-Allow-Origin when the request includes credentials (cookies, HTTP authentication). You must specify the exact origin, like https://app.example.com.

How do I fix CORS errors in development?

In development, configure your backend to allow requests from your local development origin (e.g., http://localhost:3000). Alternatively, use a proxy in your frontend build tool (Vite, webpack) to route API requests through the same origin, bypassing CORS entirely.

Is disabling CORS safe?

Disabling CORS by using Access-Control-Allow-Origin: * on all routes removes a critical browser security layer. It is acceptable for public, read-only APIs but dangerous for any endpoint that accepts credentials, modifies data, or returns private information.