Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls whether a web page from one origin may call an API on a different origin. The server declares what it permits through Access-Control response headers; the browser enforces those rules before exposing the response to JavaScript.

What is a CORS preflight request?

For requests that are not simple — custom headers, methods like PUT or DELETE, or JSON content types — the browser first sends an OPTIONS preflight asking what is allowed. The server answers with the permitted methods and headers, and a max-age telling the browser how long it may cache that answer before asking again.

Can I use a wildcard origin with credentials?

No. The CORS spec forbids combining Access-Control-Allow-Origin set to * with Access-Control-Allow-Credentials set to true. If your API sends cookies or auth headers, you must echo back the specific requesting origin, not a wildcard. This builder warns you when that combination is selected.

Why list origins per environment?

Your local, staging, and production front ends usually live on different origins. Documenting allowed origins per environment prevents the common mistake of leaving a localhost origin allowed in production, which would let a developer's machine talk to live data.

Is my configuration sent anywhere?

No. Both the policy document and the response headers are generated in your browser from your inputs. Nothing is uploaded, so you can plan CORS for internal APIs privately.

CORS Policy Documentation Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

The CORS Policy Documentation Builder produces two things from one set of inputs: a plain-language policy document for your team and the exact Access-Control-* response headers your server must send. CORS is widely misconfigured — too open and it is a security hole, too strict and the front end breaks — so writing the policy down and generating the headers from it keeps the two in sync.

How it works

You declare the allowed origins (ideally per environment), the HTTP methods and request headers to permit, whether the API sends credentials, and a preflight max-age. The tool renders a documentation section explaining each choice, then emits the corresponding headers: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials, and Access-Control-Max-Age. It also enforces the spec rule that a wildcard origin (*) cannot be combined with credentials, flagging that contradiction so you do not ship an invalid policy.

Tips and example

Never wildcard a credentialed API. If you send cookies or tokens, echo back the specific requesting origin against your allowlist; * plus credentials is rejected by browsers and is a security smell.
Scope origins per environment. Keep localhost origins out of your production allowlist so a developer machine can never reach live data.
Tune the preflight max-age. A longer Access-Control-Max-Age reduces preflight chatter but means policy changes take longer to propagate; minutes to an hour is a common balance.

Example: a production API allowing https://app.example.com, methods GET, POST, PUT, DELETE, headers Content-Type, Authorization, credentials on, with a 600-second preflight cache.