CruxDevCruxDev Tools Prompts
security Utility • Zero-Server Privacy • 100% Client-Side

CORS Header Builder

Generate Access-Control-Allow-Origin, Methods, Headers, and Credentials CORS response headers with preset configurations.

Overview

Builds an Express.js CORS middleware snippet from your Access-Control-Allow-Origin, allowed methods and allowed headers, with an optional credentials flag - and includes one warning you should read: the default combination of a wildcard origin with credentials enabled is rejected by browsers.

How It Works

Set the allow-origin value (default *), the allowed methods list, the allowed headers list, and toggle the credentials checkbox. The generated Express middleware - res.header calls for each Access-Control header plus an OPTIONS short-circuit returning 200 - regenerates live. Copy the snippet and adapt the route scaffolding around it.

Step-by-Step Usage Guide

  1. Set Access-Control-Allow-Origin to your frontend's exact origin (scheme + host + port) rather than the wildcard when credentials matter.
  2. Trim the methods and headers lists to what your API actually accepts - broad lists are a footgun, not a convenience.
  3. Toggle credentials only if your frontend really sends cookies or Authorization headers cross-origin.
  4. Copy the snippet into your Express app before your routes, then verify with a real cross-origin request from the browser.

Technical Specifications & Standards

The headers this tool emits are the server's half of the CORS protocol from the WHATWG Fetch specification: Access-Control-Allow-Origin names the one origin (or *) permitted to read the response, Allow-Methods and Allow-Headers answer the preflight, and Allow-Credentials true tells the browser to expose the response to a request that sent cookies or auth. The critical interaction the defaults illustrate: the Fetch specification forbids the wildcard origin for credentialed requests. A response carrying both Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true will not be readable in the browser - the request completes, but JavaScript is denied the body, with a console error about the wildcard. For credentialed cross-origin access the server must echo the exact request origin rather than a blanket star. The generated middleware short-circuits every OPTIONS request with a bare 200 - a common shortcut, but one that skips answering which methods and headers the preflight actually asked about, which some strict clients notice. For real applications, prefer a maintained middleware (the cors package) that handles origin echo, preflight details and Vary headers correctly; use this snippet to see the wire format and to debug what your middleware is actually sending.

Targeted Use Cases

  • Fixing the classic 'blocked by CORS policy' console error by seeing exactly which headers the server must send.
  • Debugging why credentialed requests fail even with a wildcard origin - and learning the rule that forbids it.
  • Scaffolding a minimal CORS setup for a small internal API before graduating to the cors package.
  • Teaching the preflight flow: which requests trigger OPTIONS, and what the answers mean.

Notes & Gotchas

  • Never combine Access-Control-Allow-Origin: * with Allow-Credentials: true - the Fetch specification forbids it and browsers block the response.
  • Echo the specific origin for credentialed APIs, and set the Vary: Origin header so caches do not serve one origin's answer to another.
  • Keep allowed methods and headers minimal; a permissive preflight answer is an invitation, and attackers read your headers too.
  • Prefer a battle-tested middleware such as the cors npm package in production; hand-rolled header code misses edge cases like per-request preflight answers.

Frequently Asked Questions

Why do browsers block my wildcard-plus-credentials setup?

The Fetch specification explicitly forbids Access-Control-Allow-Origin: * for credentialed requests - otherwise any website could read authenticated responses from your API. The server must echo the requesting origin exactly, and the browser enforces this before JavaScript sees the response.

Where do I put this middleware in Express?

Before your route handlers - Express applies middleware in registration order, so a CORS middleware mounted after a route never runs for it. Register it early, before anything that can terminate the request with a response.

What is the OPTIONS short-circuit doing?

Browsers send a preflight OPTIONS request before 'non-simple' requests. The snippet answers every OPTIONS with 200 and the CORS headers, skipping your real handlers. It works, but it answers preflights less precisely than a dedicated CORS middleware, which inspects what the browser asked.

Does CORS protect my API from attackers?

Not by itself. CORS is a browser-enforced reading policy, not authentication - non-browser clients ignore it entirely. Your API still needs real authentication and authorization; CORS only stops a browser page on another origin from reading responses.