Can I use a wildcard origin with credentials?

No. When Access-Control-Allow-Credentials is true, the spec forbids a wildcard '*' origin — browsers will reject the response. You must echo back a specific allowed origin instead, which this builder does for you.

What is a CORS preflight request?

For non-simple requests the browser first sends an OPTIONS request asking which methods and headers are permitted. Your server must answer it with the matching Access-Control-Allow-* headers and a 204 or 200 status before the real request is sent.

Why does my fetch still fail after adding CORS?

Common causes are a missing OPTIONS handler, an origin that does not match exactly (scheme, host, and port must all match), or credentials mode mismatched between the client and server. Check the browser console for the exact blocked header.

Does CORS make my API secure?

No. CORS only controls which browser origins may read responses; it is not an authorization mechanism. Non-browser clients ignore it entirely. Always enforce real authentication and authorization on the server.

What does Access-Control-Max-Age do?

It tells the browser how many seconds it may cache the preflight response, so repeated requests skip the OPTIONS round-trip. Setting it to a few hours reduces preflight overhead for chatty APIs.

CORS Configuration Builder

Generate correct CORS config for your stack

Cross-Origin Resource Sharing (CORS) is the browser security mechanism that controls whether JavaScript running on one origin may read responses from a different origin. Getting the headers slightly wrong leads to the familiar “blocked by CORS policy” error. This builder takes your allowed origins, methods, headers, credentials mode, and preflight cache, then emits a tested configuration for Express (cors middleware), Fastify (@fastify/cors), or plain Nginx add_header directives.

How it works

CORS is enforced entirely by the browser using a set of Access-Control-* response headers. For a “simple” request the browser sends the call directly and checks the Access-Control-Allow-Origin header on the response. For anything else — custom headers, PUT/DELETE, JSON bodies — it first issues a preflight OPTIONS request, and your server must answer with the allowed methods and headers:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

The key rule the builder enforces: when credentials are enabled you cannot use the * wildcard origin. Instead the server must compare the incoming Origin header against an allow-list and echo back the exact match, which is why the generated Express and Fastify snippets use an origin callback function rather than a static string.

Tips and notes

Match origins exactly — https://example.com and https://www.example.com are different origins, and the port matters too (:3000 vs :8080).
The Nginx snippet includes a dedicated if ($request_method = OPTIONS) block that returns 204 for preflight, because Nginx will not run your application for OPTIONS unless you handle it.
Keep the allowed-headers list tight; only list headers your client actually sends, such as Content-Type and Authorization.
CORS protects browser reads only — never rely on it for access control on server-to-server or mobile API traffic.

CORS Configuration Builder

Email me this result

Generate correct CORS config for your stack

How it works

Tips and notes