CORS Header Builder

Generate CORS configuration for Nginx, Express, Spring Boot, or raw headers.

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

CORS Header Builder — What It Does

Select your allowed origins, HTTP methods, headers, and credentials policy, then instantly get the correct CORS configuration in four formats: raw HTTP headers, Nginx config block, Express.js middleware, and Spring Boot annotation. Copy the output directly into your project.

Key CORS Headers Explained

  • Access-Control-Allow-Origin — Specifies which origin(s) can access the resource. Set to a specific domain or * for public APIs.
  • Access-Control-Allow-Methods — Lists the HTTP methods the server accepts from cross-origin requests (e.g. GET, POST, PUT, DELETE).
  • Access-Control-Allow-Headers — Lists custom request headers the client is allowed to send (e.g. Authorization, Content-Type, X-Request-ID).
  • Access-Control-Allow-Credentials — When set to true, the browser will include cookies and auth headers. Cannot be used with * origin.
  • Access-Control-Max-Age — How long (in seconds) the browser should cache the preflight response, reducing OPTIONS requests.

The Preflight Flow

When a browser detects a "non-simple" cross-origin request (custom headers, methods other than GET/POST, or JSON content type), it sends an automatic OPTIONS preflight request first. The server must respond with the appropriate CORS headers and a 204 No Content status. Only then does the browser proceed with the actual request. If the preflight fails, the browser blocks the request entirely.

Common Mistakes

  • Wildcard + credentials — Setting Access-Control-Allow-Origin: * with credentials: true is invalid and the browser will reject all requests.
  • Missing OPTIONS handler — Many server frameworks don't handle OPTIONS by default. If the preflight returns a 404 or 405, CORS fails silently.
  • Forgetting Vary: Origin — When dynamically echoing the request origin, always include Vary: Origin so CDNs and proxies don't cache the wrong origin header.

Frequently Asked Questions

What is CORS and why do I need it?
Cross-Origin Resource Sharing (CORS) is a browser security mechanism that blocks web pages from making requests to a different domain than the one serving the page. If your frontend at app.example.com needs to call an API at api.example.com, the API server must send CORS headers explicitly allowing that origin.
What does Access-Control-Allow-Origin: * mean?
The wildcard * allows any origin to make requests. This is fine for public read-only APIs but dangerous for authenticated endpoints — browsers will not send cookies or Authorization headers when the origin is a wildcard with credentials enabled.
Why does my browser send an OPTIONS request before the actual request?
This is called a preflight request. Browsers automatically send it for non-simple requests (e.g. those with custom headers, PUT/DELETE methods, or JSON content type) to check whether the server allows the actual request. The server must respond to OPTIONS with the correct CORS headers.
Can I allow multiple specific origins?
The Access-Control-Allow-Origin header only accepts a single origin or *. To allow multiple specific origins, your server must read the request Origin header, check it against an allowlist, and dynamically echo back the matching origin.
What is the difference between CORS headers and a proxy?
CORS headers tell the browser to relax its same-origin restriction. A proxy routes the request through your own server so the browser sees it as same-origin — no CORS headers needed. Proxies add latency but work when you cannot control the target API server.