How to Add CORS Middleware to an Express API

Why browsers block the request (and curl doesn't)

CORS is a browser construct, not an HTTP protocol rule. When a browser sees a fetch to a different origin, it checks the response for an Access-Control-Allow-Origin header before handing the data to your JavaScript. curl and Postman skip that check entirely - they are not browsers.

So the API is not broken. It just has no CORS headers. Browsers refuse the response; curl succeeds. The fix is a middleware that attaches the headers to every response.

The middleware

Register it with app.use() before any route handler so every response gets the headers:

app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  if (req.method === 'OPTIONS') {
    return res.status(204).end();
  }

  next();
});

• Access-Control-Allow-Origin: * tells browsers any origin may read the response.
• Access-Control-Allow-Methods lists every method your API accepts.
• Access-Control-Allow-Headers lists the request headers callers are allowed to send.
• The OPTIONS short-circuit returns 204 No Content immediately - no body needed.

Why OPTIONS needs special handling

Before sending a POST, PUT, or any request with a custom header, the browser sends an automatic preflight using the OPTIONS method. If your route handlers don't define OPTIONS, Express returns 404 and the browser aborts before the real request ever fires. The middleware above intercepts every OPTIONS call and returns 204 with the CORS headers, so the preflight succeeds.

Verify it:

# Preflight - should return 204 with Access-Control headers
curl -v -X OPTIONS http://localhost:3000/tasks

# Real request - headers should appear on the response
curl -sD - http://localhost:3000/tasks | grep -i access-control

When to tighten the wildcard

Access-Control-Allow-Origin: * is fine for public, read-only APIs. Two scenarios require a specific origin instead of *:

• Cookie-authenticated requests - credentials: 'include' requires the server to echo the exact Origin header back, not *.
• Private APIs - a wildcard lets any website call your API from a user's browser.

Production CORS middleware usually reads req.headers.origin, checks it against an allowlist, and echoes it back if it matches:

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

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (ALLOWED.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  res.setHeader('Vary', 'Origin');    // tell caches this header changes per origin

  if (req.method === 'OPTIONS') return res.status(204).end();
  next();
});

The Vary: Origin header tells CDNs and proxies not to serve one origin's cached response to another.