Why does the tool refuse "*" as an origin when credentials are enabled?

This mirrors a real browser/CORS spec restriction: when Access-Control-Allow-Credentials is true, the Access-Control-Allow-Origin header cannot be the wildcard "*", browsers reject that combination outright. You must list specific origins instead whenever credentials (cookies, HTTP auth) need to be sent cross-origin.

What's the difference between allowed methods and allowed headers?

Allowed methods (GET, POST, PUT, etc.) control which HTTP verbs a cross-origin request can use. Allowed headers control which custom request headers (like Authorization or X-Custom-Header) the browser is permitted to send. Both matter for preflighted (OPTIONS) requests, a request using a non-simple method or header triggers a preflight the server must answer correctly.

Does this handle the browser's preflight OPTIONS request?

The Nginx output includes an explicit block that returns 204 for OPTIONS requests, since Nginx doesn't handle CORS natively. The Express, Next.js, and Spring Boot outputs rely on their respective CORS middleware/library to handle preflight automatically, that's part of what those libraries are for.

Is enabling credentials always the right choice?

Only enable it if your cross-origin requests genuinely need to send cookies or HTTP authentication. It requires the client to also opt in (e.g. fetch's credentials: 'include') and forces you to list specific origins instead of a wildcard, so leave it off for simple public APIs that don't rely on cookie-based sessions.

CORS Config Generator - Express, Next.js, Nginx, Apache, Spring Boot

Overview

Introduction

CORS misconfiguration is a common source of both broken cross-origin requests (too strict) and accidental security holes (too permissive, especially combined with credentials), and each framework has its own way of expressing the same handful of settings.

This tool builds a CORS configuration from origins, methods, headers, and a credentials toggle, and outputs it as the real syntax for five common server/framework targets.

What Is CORS Configuration Generator?

A CORS config generator covering Express (the cors npm package), Next.js (next.config.js's headers() function), Nginx (add_header directives with an OPTIONS short-circuit), Apache (mod_headers), and Spring Boot (a CorsFilter @Bean).

Inputs are the same regardless of framework, repeatable allowed origins, a set of allowed HTTP methods, a comma-separated allowed headers list, and a credentials toggle, only the generated syntax changes.

How CORS Configuration Generator Works

Your origins, methods, and headers are validated (at least one origin and one method required, no wildcard origin combined with credentials) then formatted into whichever native structure your chosen framework expects, a JavaScript object literal, a next.config.js headers array, Nginx add_header lines, Apache Header directives, or a Java CorsConfiguration object.

The credentials toggle sets the corresponding Access-Control-Allow-Credentials value (or Spring's setAllowCredentials call) consistently across every framework's output.

When To Use CORS Configuration Generator

Use it when setting up or fixing CORS for an API that a frontend on a different origin needs to call.

It's also useful for translating a working CORS setup from one framework to another during a migration, rebuild the same origins/methods/headers and get correct output in the new stack's syntax.

Often used alongside CSP Header Generator and HTTP Security Headers Generator.

Features

Advantages

Outputs real, framework-idiomatic syntax (the actual cors package call, a real next.config.js shape, a real Spring @Bean) rather than pseudocode.
Enforces the wildcard-plus-credentials restriction that browsers themselves enforce, catching a common misconfiguration before you deploy it.
Covers both application-level frameworks (Express, Next.js, Spring Boot) and web-server-level config (Nginx, Apache) in one tool.

Limitations

Nginx's generated block is a simplified starting point, real-world Nginx CORS setups often need more nuanced logic (e.g. reflecting one of several allowed origins dynamically) that a static snippet can't fully capture.
Doesn't validate that your listed origins are well-formed URLs, only that the field isn't empty.

Examples

A credentialed Express API allowing one frontend origin

Input

framework: Express, origin: https://app.example.com, methods: GET, POST, credentials: true

Output

const cors = require("cors");

app.use(cors({
  origin: "https://app.example.com",
  methods: ["GET", "POST"],
  credentials: true,
}));

A single specific origin (required since credentials is true) is passed directly as the origin option, alongside the selected methods and credentials: true.

Best Practices & Notes

Best Practices

List only the specific origins that genuinely need cross-origin access; avoid a wildcard even when credentials aren't involved, unless you're building a truly public, unauthenticated API.
Only allow the HTTP methods and headers your API actually uses, a narrower allow-list is easier to reason about and slightly reduces attack surface.
Test preflight (OPTIONS) behavior directly with a tool like curl -X OPTIONS after deploying, especially for the Nginx config, since it's the one target here without a dedicated CORS library handling edge cases for you.

Developer Notes

Each framework branch builds the same logical config (origins, methods, headers, credentials) into that framework's native representation; the wildcard-plus-credentials check is enforced identically across all five outputs, since it's a browser/CORS-spec-level restriction rather than something framework-specific.

CORS Configuration Generator Use Cases

Setting up CORS for an API consumed by a frontend on a different origin/subdomain
Fixing an overly permissive or overly restrictive existing CORS configuration
Migrating a working CORS setup from one server/framework to another during a stack change

Common Mistakes

Trying to combine a wildcard origin with credentials: true, which browsers reject regardless of what the server sends.
Allowing every HTTP method and header by default instead of listing only the ones actually needed, widening the API's surface unnecessarily.

Tips

Pair this with the HTTP Security Headers Generator for the rest of your response header baseline (HSTS, X-Frame-Options, Permissions-Policy) alongside your CORS setup.

CORS Configuration Generator