* with credentials is invalid per CORS spec. The browser will block the request.
CORS Configuration Generator builds the correct HTTP response headers for Cross-Origin Resource Sharing based on your security requirements. Configure the allowed origins, methods, headers, credentials policy, and preflight cache duration — the tool generates the corresponding HTTP headers and optionally the configuration snippets for nginx, Apache, Express.js, and Cloudflare Workers.
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts JavaScript from making requests to a different origin (domain, protocol, or port) than the one that served the page. Without CORS headers, a browser blocks all cross-origin API requests. APIs that need to be called from browser clients on different domains must return specific headers to explicitly permit those requests.
The key CORS headers: Access-Control-Allow-Origin specifies which origins can access the resource (* for all, or specific origin). Access-Control-Allow-Methods lists allowed HTTP methods. Access-Control-Allow-Headers lists allowed request headers. Access-Control-Allow-Credentials: true allows cookies and auth headers (requires a specific origin, not *). Access-Control-Max-Age caches preflight responses for N seconds.
Public API open to any origin
Result: Access-Control-Allow-Origin: * / Allow-Methods: GET, OPTIONS — no credentials
Auth API with cookies
Result: Access-Control-Allow-Origin: https://app.example.com / Allow-Credentials: true — specific origin required
Express.js middleware
Result: app.use(cors({ origin: 'https://app.example.com', credentials: true, methods: ['GET','POST'] }))
Why can't I use Access-Control-Allow-Origin: * with credentials?
The CORS spec prohibits this combination as a security measure. If a wildcard origin were allowed with credentials, any website could make authenticated requests to your API using the visitor's credentials (cookies, session tokens). The browser enforces: if Allow-Credentials is true, the Allow-Origin header must be an explicit origin, not a wildcard. Your origin must match the request's Origin header exactly.
What is a preflight request?
For non-simple requests (using methods other than GET/POST/HEAD, or custom headers, or application/json content type), browsers send an OPTIONS preflight request before the actual request to check if the server allows it. The preflight includes Access-Control-Request-Method and Access-Control-Request-Headers. The server must respond with matching Allow headers for the actual request to proceed. Use Access-Control-Max-Age to cache preflight responses and reduce OPTIONS request overhead.
What is the difference between CORS and CSRF?
CORS controls which websites can read your API responses (same-origin policy enforcement). CSRF (Cross-Site Request Forgery) is an attack where a malicious site causes a user's browser to make unintended requests to your API using the user's credentials. CORS doesn't protect against CSRF — a malicious site can still trigger a state-changing POST request even if the browser blocks reading the response. Protect against CSRF with SameSite=Lax cookies and CSRF tokens.
How do I handle CORS in development (localhost)?
In development, your frontend might run on localhost:3000 and your API on localhost:8080 — these are different origins (different ports). Configure your API to allow http://localhost:3000 as an origin. Do not use * in development with credentials. Use environment-specific CORS configurations: strict in production (specific origins), permissive in development. Many frameworks detect the NODE_ENV and apply the appropriate CORS settings.
Why do I get CORS errors even after setting the headers?
Common issues: 1. The error is a preflight failure — check that OPTIONS requests return the correct headers. 2. The Allow-Origin header must exactly match the request Origin header (protocol + domain + port). 'https://example.com' ≠ 'http://example.com' ≠ 'https://www.example.com'. 3. Multiple Allow-Origin headers — use only one. 4. Proxy/load balancer strips the CORS headers — check the response at each layer. 5. Browser cache — clear cache after changing CORS configuration.