No 'Access-Control-Allow-Origin' Header Is Present: Fix CORS

TL;DR: The response to your cross-origin request had no Access-Control-Allow-Origin header matching the page’s origin, so the browser hid it from your script. Add the header on the server that owns the resource, on every response including errors and the OPTIONS preflight. The client cannot fix this.

What it means

When JavaScript on https://app.example.com calls https://api.example.com, the browser sends the request with an Origin header and then inspects the response. If the response does not contain Access-Control-Allow-Origin with either that exact origin or * (for requests without credentials), the browser discards the body and raises the error above. The request usually did reach the server. Side effects of a POST may have already happened.

This is the check defined in the WHATWG Fetch Standard. The wording differs by browser, but the cause is the same:

Chrome:  No 'Access-Control-Allow-Origin' header is present on the requested resource.
Firefox: (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.
Safari:  Origin https://app.example.com is not allowed by Access-Control-Allow-Origin. Status code: 200
         Fetch API cannot load https://api.example.com/items due to access control checks.

Firefox also prints (Reason: CORS request did not succeed) when there was no HTTP response at all, such as a DNS failure, a TLS error, a blocked mixed-content request or a connection reset. That variant is not a missing header; fix the network failure first.

Who sent it?

The browser generated the message, but the missing header is the fault of whichever layer produced the response you received. Look at that response in DevTools, Network tab, rather than at the console message.

• Response has Server: nginx or your framework’s header and a normal body: the origin application or its nginx is not adding the header.
• Response has Server: cloudflare and a CF-Ray header, or X-Amz-Cf-Id (CloudFront), X-Amzn-Trace-Id (API Gateway or ALB): a CDN or gateway answered. A 4xx or 5xx generated by the gateway itself will not carry your application’s CORS headers.
• No response at all (status (failed) or (blocked)): it is not a header problem. Check for mixed content, an ad blocker, a certificate error, or an unreachable host.
• Status is a 301 or 302: a redirect response has no CORS headers, and a preflight is not allowed to be redirected. Call the final URL directly (https, correct host, trailing slash).

Reproduce it outside the browser by sending the Origin header yourself, because many servers only emit CORS headers when Origin is present:

curl -si https://api.example.com/items \
  -H 'Origin: https://app.example.com' | grep -iE '^(HTTP|access-control|vary|server)'

A healthy answer looks like this:

HTTP/2 200
access-control-allow-origin: https://app.example.com
vary: Origin

For a preflight, add the method and headers the browser would ask about:

curl -si -X OPTIONS https://api.example.com/items \
  -H 'Origin: https://app.example.com' \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: content-type,authorization'

You want a 2xx (204 is typical) with Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers that cover what was requested.

Fix it, in order of likelihood

1. Confirm which URL is failing. Compare the URL in the console message with the one you think you are calling. A typo in the host, http instead of https, or a missing /api prefix often lands on a different server or a 404 handler with no CORS configuration.
2. Add the header on the server that owns the resource, not on the client.
3. Make sure it is added to every response: errors (401, 404, 500), redirects, and the OPTIONS preflight. Middleware order matters; the CORS handler must run before auth and body parsing.
4. Reflect the request origin from an allowlist rather than hard-coding * if cookies or Authorization are involved, and send Vary: Origin.
5. If something sits in front (CDN, API gateway, load balancer), check that it forwards the Origin header and does not cache one origin’s response for another.
6. Re-test with curl using the Origin header, then hard-reload the page. Browsers cache preflight results for Access-Control-Max-Age seconds (Chromium caps it at 7200 seconds, Firefox at 86400), so a fixed server can still look broken for a while.

Express (cors package)

import express from 'express'
import cors from 'cors'

const app = express()

const allowed = new Set(['https://app.example.com', 'https://admin.example.com'])

app.use(
  cors({
    origin(origin, callback) {
      // Requests with no Origin (curl, server-to-server) are not CORS requests
      if (!origin || allowed.has(origin)) return callback(null, true)
      callback(null, false) // omit the header; do not throw, or you get a 500 with no CORS headers
    },
    credentials: true, // sends Access-Control-Allow-Credentials: true
    methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
    allowedHeaders: ['Content-Type', 'Authorization'],
    maxAge: 600
  })
)

// Register routes AFTER cors(), otherwise early errors skip it
app.use('/items', itemsRouter)

app.use(cors(...)) also answers OPTIONS preflights for every route. The cors package sets Vary: Origin itself when the origin is dynamic.

nginx

The classic mistake is add_header without always. Without it, nginx only adds the header to 200, 201, 204, 206, 301, 302, 303, 304, 307 and 308 responses, so your 401, 404 and 502 pages look like CORS failures. A second trap: add_header directives are inherited from the enclosing level only if the current level defines none, so a single add_header inside a location (or if) silently discards the ones set above it. That is why the if block below repeats every header.

map $http_origin $cors_origin {
    default                      "";
    "https://app.example.com"    $http_origin;
    "https://admin.example.com"  $http_origin;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    location / {
        # An empty value means nginx does not emit the header at all
        add_header Access-Control-Allow-Origin      $cors_origin always;
        add_header Access-Control-Allow-Credentials "true" always;
        add_header Vary                             "Origin" always;

        if ($request_method = OPTIONS) {
            add_header Access-Control-Allow-Origin  $cors_origin always;
            add_header Access-Control-Allow-Credentials "true" always;
            add_header Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS" always;
            add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
            add_header Access-Control-Max-Age       600 always;
            add_header Vary                         "Origin" always;
            return 204;
        }

        proxy_pass http://app_backend;
    }
}

If the upstream application already sends CORS headers, do not add them again in nginx. Duplicated Access-Control-Allow-Origin values are rejected by Chrome with a different error (The 'Access-Control-Allow-Origin' header contains multiple values '...', but only one is allowed). Use proxy_hide_header Access-Control-Allow-Origin; before add_header if you want nginx to own the policy.

Cloudflare Workers

const ALLOWED = new Set(['https://app.example.com'])

function corsHeaders(origin) {
  const h = new Headers()
  if (origin && ALLOWED.has(origin)) {
    h.set('Access-Control-Allow-Origin', origin)
    h.set('Access-Control-Allow-Credentials', 'true')
  }
  return h
}

export default {
  async fetch(request) {
    const origin = request.headers.get('Origin')

    if (request.method === 'OPTIONS') {
      const h = corsHeaders(origin)
      h.set('Vary', 'Origin, Access-Control-Request-Headers')
      h.set('Access-Control-Allow-Methods', 'GET, POST, OPTIONS')
      h.set('Access-Control-Allow-Headers', request.headers.get('Access-Control-Request-Headers') || 'Content-Type')
      h.set('Access-Control-Max-Age', '600')
      return new Response(null, { status: 204, headers: h })
    }

    const upstream = await fetch(request)
    // Response from fetch() is immutable; copy it to change headers
    const response = new Response(upstream.body, upstream)
    for (const [k, v] of corsHeaders(origin)) response.headers.set(k, v)
    response.headers.append('Vary', 'Origin') // append: the origin may already send Vary: Accept-Encoding
    return response
  }
}

Amazon S3 (and CloudFront in front of it)

S3 only emits CORS headers when the request carries an Origin header and a rule matches. In the bucket’s Permissions tab, under Cross-origin resource sharing (CORS), paste a JSON array of rules:

[
  {
    "AllowedOrigins": ["https://app.example.com"],
    "AllowedMethods": ["GET", "HEAD", "PUT"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

With CloudFront in front, the distribution must forward Origin to S3 and include it in the cache key, otherwise CloudFront can cache a response made without Origin (no CORS headers) and serve it to everyone. Put Origin in the cache key with a cache policy that whitelists it, and forward it to S3 with the managed CORS-S3Origin origin request policy. Alternatively, add CORS headers at the edge with a response headers policy and skip S3 CORS.

API Gateway

For an HTTP API, set the CORS configuration on the API (AllowOrigins, AllowMethods, AllowHeaders, optionally AllowCredentials, MaxAge). When it is configured, API Gateway answers preflights itself and applies its own headers to responses. For a REST API with Lambda proxy integration, “Enable CORS” only creates the OPTIONS mock; your Lambda must return Access-Control-Allow-Origin in its own response, and gateway-generated errors (403 from an authorizer, 429 throttling, 5xx) need CORS headers added through Gateway Responses.

Next.js route handlers

// app/api/items/route.ts
const ALLOWED = new Set(['https://app.example.com'])

function cors(origin: string | null) {
  const headers: Record<string, string> = { Vary: 'Origin' }
  if (origin && ALLOWED.has(origin)) {
    headers['Access-Control-Allow-Origin'] = origin
    headers['Access-Control-Allow-Credentials'] = 'true'
  }
  return headers
}

export async function OPTIONS(request: Request) {
  return new Response(null, {
    status: 204,
    headers: {
      ...cors(request.headers.get('origin')),
      'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
      'Access-Control-Allow-Headers': 'Content-Type, Authorization',
      'Access-Control-Max-Age': '600'
    }
  })
}

export async function GET(request: Request) {
  return Response.json({ items: [] }, { headers: cors(request.headers.get('origin')) })
}

For a single fixed origin you can instead set headers() in next.config for /api/:path*. It cannot reflect the origin from an allowlist.

Django and Flask

# Django: pip install django-cors-headers
INSTALLED_APPS = [..., 'corsheaders']
MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',   # as high as possible, before CommonMiddleware
    'django.middleware.common.CommonMiddleware',
    ...
]
CORS_ALLOWED_ORIGINS = ['https://app.example.com']
CORS_ALLOW_CREDENTIALS = True

# Flask: pip install flask-cors
from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app, origins=['https://app.example.com'], supports_credentials=True, max_age=600)

Credentials and the wildcard rule

If the request uses credentials: 'include' (cookies, client certificates) the response must contain a specific origin, not *, plus Access-Control-Allow-Credentials: true. An Authorization header set manually in JavaScript is not “credentials” in the Fetch sense, but it does force a preflight, and the preflight must list Authorization by name in Access-Control-Allow-Headers: even without credentials, a * there does not cover it (MDN). On credentialed requests, * in Access-Control-Allow-Headers and Access-Control-Allow-Methods is treated as a literal string, not a wildcard. Name each one.

Never reflect an arbitrary Origin value back with credentials enabled. That makes every site on the internet a trusted origin for your logged-in users. Match against an allowlist.

Why it works in Postman and curl

Nothing in the HTTP exchange changes. Postman and curl send the same request and receive the same bytes. They just do not apply the same-origin policy, which exists to protect users’ browser sessions, not your API. A server that “works in Postman” has not proven it is CORS-correct. It has proven it is reachable. The only useful test is to replay the request with the same Origin header and, for non-simple requests, the same preflight.

Related

• Debugging CORS errors covers the other CORS failure messages.
• Failed CORS preflight for Response to preflight request doesn't pass access control check.
• Access-Control-Allow-Origin, Access-Control-Allow-Credentials and Vary for the header semantics.
• CORS guide for the model behind simple versus preflighted requests.
• The CORS debugger lets you test an endpoint with a chosen origin.