CORS Generator

Stop Debugging CORS Errors by Hand

It’s 10 PM. Your React app on localhost:3000 can’t talk to your Express API on localhost:8080. The console screams about Access-Control-Allow-Origin. You start copy-pasting Stack Overflow snippets, and suddenly you’ve got a wildcard origin mixed with credentials, which the CORS spec explicitly forbids. Sound familiar?

CORS is a browser security mechanism that blocks cross-origin requests unless the server explicitly opts in through HTTP headers. The concept is straightforward. The implementation is full of footguns.

This tool generates the correct CORS configuration for Express.js, Nginx, and Apache. Toggle your options, grab the snippet, drop it in your config. Done.

The CORS Gotchas That Burn Everyone

Wildcard + credentials = broken. You can’t set Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true at the same time. The browser will reject it. If your API uses cookies or HTTP auth, you need the exact origin.

Preflight requests exist. When a browser sees a non-simple request (PUT, DELETE, custom headers like Authorization), it fires an OPTIONS request first. If your server doesn’t respond to OPTIONS with the right CORS headers, the actual request never gets sent. The tool handles this by generating the correct OPTIONS response config.

Origin matching is strict. https://app.example.com and https://app.example.com:443 are the same origin, but http://app.example.com isn’t. Forgetting the protocol or including an extra port trips people up constantly.

Max-Age saves requests. Without Access-Control-Max-Age, the browser might send a preflight OPTIONS request before every single API call. Set it to 86400 (one day) and the browser caches the preflight response.

How to Build Your Config

1. Set the allowed origin. Use * for a public API with no auth, or enter exact domains like https://app.example.com.
2. Check off the HTTP methods your API supports — GET, POST, PUT, DELETE, PATCH.
3. Add the headers your API expects: Content-Type, Authorization, whatever custom headers you’re using.
4. Turn on credentials support if your API uses cookies or session-based auth.
5. Set Max-Age to something reasonable (86400 is a solid default).
6. Pick your server platform and copy the output.

For Express, you get middleware code. For Nginx, it’s add_header directives in a location block. For Apache, it’s .htaccess rules with Header set.

Real Deployment Scenarios

Your SPA is on a CDN at app.example.com. Your API lives at api.example.com. The API server needs CORS headers allowing https://app.example.com specifically — not a wildcard, because the app sends auth tokens.

In a microservices setup, each service might need different CORS policies. Your public search API allows *. Your admin API only allows https://admin.internal.com. Generate each config separately.

During local development, you’ve probably got three or four services on different ports. Rather than disabling browser security with a Chrome flag (don’t), configure CORS properly for each dev service. You’ll catch misconfiguration issues before they hit production.

The CSP Generator on Toolsvu builds Content Security Policy headers through a similar visual interface — it’s the natural companion when you’re hardening your HTTP security headers.