CORS Policy Generator

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts web pages from making requests to a different origin (domain, protocol, or port) than the one that served the page. Browsers enforce it to prevent malicious websites from silently reading data from APIs you're authenticated with. It only applies to browser-initiated requests — server-to-server calls are unaffected. The server opts in to cross-origin access by returning the appropriate Access-Control-* response headers.

A preflight is an automatic OPTIONS request the browser sends before the actual cross-origin request. It happens when the request uses a non-simple method (anything other than GET/POST/HEAD), includes custom headers (like Authorization or Content-Type: application/json), or streams request bodies. The server must respond to the preflight with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers before the browser will proceed with the real request. The Access-Control-Max-Age header tells the browser how long to cache the preflight result.

The CORS spec explicitly forbids using the wildcard origin (*) when credentials (cookies, HTTP auth, or client-side certificates) are involved. This is intentional: if any origin could read authenticated responses, it would defeat the entire purpose of cookie-based authentication. When credentials: true is set, you must specify an exact origin in Access-Control-Allow-Origin, and also set Access-Control-Allow-Credentials: true. In practice, you reflect the requesting origin from a server-side allowlist.

Access-Control-Allow-Headers lists the request headers the browser is permitted to include in the actual cross-origin request (e.g. Authorization, Content-Type). The browser checks this during the preflight. Access-Control-Expose-Headers, on the other hand, controls which response headers JavaScript can read via response.headers.get(). By default, only a small set of 'CORS-safelisted' response headers (like Content-Type and Cache-Control) are accessible. If your API returns custom headers like X-RateLimit-Remaining or X-Request-Id that clients need, list them in Access-Control-Expose-Headers.

CORS headers only support a single origin value at a time (or *). To allow multiple specific origins, you need server logic: check the incoming Origin request header against an allowlist and reflect it back if it matches. In Express, the cors package handles this automatically when you pass an array of origins. In Nginx, use a map block to map incoming origins to the correct header value. In Next.js, check process.env allowlist inside middleware.ts. Never reflect arbitrary origins — always validate against a hardcoded set.

No. CORS is purely a browser enforcement mechanism — it has no effect on server-to-server requests, curl, Postman, or any non-browser client. A motivated attacker can bypass CORS entirely. It protects your users (prevents malicious websites from silently using their browser credentials to call your API), not your server endpoints. For actual API security, use authentication tokens, rate limiting, input validation, and IP allowlists where appropriate.