API development

CORS Configuration Generator

Generate a starting-point CORS configuration for Express, NestJS, FastAPI, Nginx, Next.js headers, and Cloudflare Workers from your allowed origins, methods, and credential requirements.

Free to use · Runs in your browser · No account required

Processed locally in your browser

Nothing you enter here is uploaded, transmitted to a server, or stored by this tool. Origins and settings you enter are only used to render code locally — not transmitted anywhere.

Runs entirely in your browser — nothing is sent to a server

One origin per line, or comma-separated. Use * only for public, non-credentialed APIs.

Methods and headers

Allowed methods

Comma-separated.

Headers your frontend can read from the response, comma-separated.

  • No allowed origins configured — browser requests will be rejected until you add at least one.

Generated configuration

const cors = require("cors");

// The "cors" package itself reflects only the matching request origin — it never
// emits an invalid comma-separated Access-Control-Allow-Origin header.
app.use(
  cors({
    origin: [],
    methods: ["GET", "POST"],
    allowedHeaders: ["Content-Type", "Authorization"],
    exposedHeaders: [],
    credentials: false,
    maxAge: 600,
  }),
);

Starting point only — review it against your framework version and deployment topology before shipping.

How to use this tool

  1. 1List every origin your API must accept requests from — one per line.
  2. 2Select allowed methods and headers, and turn on credentials only if you actually use cookies or Authorization headers cross-origin.
  3. 3Pick your framework and copy the generated starting-point configuration.
  4. 4Review the warnings panel — it flags an invalid wildcard/credentials combination before you ship it.

CORS, preflight requests, and credentials

Cross-Origin Resource Sharing is a browser-enforced check, not a server-side security boundary — it protects users of a browser from a malicious page silently reading responses from another origin on their behalf. For "non-simple" requests (custom headers, methods beyond GET/POST/HEAD, or certain content types), the browser first sends an OPTIONS preflight request asking the server which origins, methods, and headers it allows, then only sends the real request if the answer permits it.

Access-Control-Allow-Origin: * cannot be combined with credentialed requests. When a request carries cookies or an Authorization header (credentials: "include" or withCredentials), browsers require the server to echo back a specific origin — never a wildcard — plus Access-Control-Allow-Credentials: true. This tool enforces that automatically.

Reflecting arbitrary origins is a common mistake. Naively echoing back whatever Origin header a request sends — for every origin, no allow-list check — effectively disables the browser's protection. Always validate the incoming origin against an explicit list before reflecting it.

Frequently asked questions

Can I combine a wildcard origin with credentials?

No. Browsers reject `Access-Control-Allow-Origin: *` when a request carries credentials (cookies or HTTP auth). This generator switches to explicit allow-list logic automatically once credentials are enabled.

What happens with multiple allowed origins?

The Access-Control-Allow-Origin header can only ever contain one origin (or `*`) per response — never a comma-separated list. This tool generates allow-list logic that echoes back the matching request origin instead.

Is the generated code production-ready?

Treat it as a reviewed starting point. Confirm it matches your framework version, deployment topology, and security requirements before shipping.

Related writing

Planned — not yet published

  • Planned
    CORS explained: what the preflight request actually checks— Simple vs preflighted requests, and why OPTIONS shows up in logs.
  • Planned
    Why Access-Control-Allow-Origin: * breaks credentialed requests— The credentials + wildcard-origin conflict, with browser error text.
  • Planned
    Reflecting origins safely: allow-lists vs regex vs wildcard subdomains— Patterns that avoid accidentally trusting attacker-controlled origins.

Related tools