CORS Config Generator

Why the browser blocks cross-origin calls

The same-origin policy stops a page on one origin from reading responses from another. CORS is the controlled exception: the server opts in by returning headers that tell the browser which other origins may read its responses. A CORS generator helps you produce those response headers correctly, because getting them subtly wrong is the usual cause of the dreaded blocked-by-CORS error.

Simple vs preflighted requests

Plain GETs and basic POSTs go straight through, and the browser just checks the response headers. Anything with a custom header, a PUT/DELETE, or a JSON content type triggers a preflight: the browser first sends an OPTIONS request asking whether the real request is allowed. Forgetting to answer that preflight is why a request that works in curl fails in the browser.

Example

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600

Max-Age lets the browser cache the preflight result so it is not repeated on every call.

The wildcard and credentials trap

You cannot combine Access-Control-Allow-Origin: * with Allow-Credentials: true. If the request sends cookies or an auth header, the browser requires an explicit origin, not a wildcard, and will reject the response otherwise. Echoing back the request origin after validating it against an allowlist is the safe pattern; blindly reflecting any origin effectively disables the protection.

FAQ

CORS blocked my request but the server returned 200, why? The server ran the request fine; the browser then refused to expose the response to your script because the headers did not permit your origin.

Does CORS protect my API from attackers? No. It is a browser enforcement, not server authorization. Tools outside the browser ignore it entirely, so you still need real auth.