CORS Policy Tester

Test and debug Cross-Origin Resource Sharing policies for any endpoint

Comma-separated header names
CORS Headers Analysis
Raw Response Headers

Status

-

CORS Allowed

-

Credentials

-

Understanding CORS

How Cross-Origin Resource Sharing protects web applications

What is CORS?

CORS is a security mechanism that allows servers to specify which origins can access their resources. Browsers enforce these policies to prevent unauthorized cross-origin requests.

Preflight Requests

For non-simple requests, browsers send an OPTIONS preflight request first to check if the server allows the actual request method, headers, and origin.

CORS and Auth

Authentication APIs must configure CORS carefully to allow frontend applications to send credentials while preventing unauthorized origins from accessing protected endpoints.

How CORS actually works

The preflight

For anything beyond a simple request, the browser sends an OPTIONS request first, carrying Origin, Access-Control-Request-Method, and Access-Control-Request-Headers. The server must answer with matching Access-Control-Allow-* headers before the real request is sent.

A request stops being simple as soon as it uses a method other than GET, HEAD, or POST, or sets a header outside a small safelist. An Authorization header triggers a preflight every time — which is why auth calls hit CORS problems that unauthenticated calls don't.

Credentials change the rules

When a request sends cookies or uses credentials: 'include', the server must return Access-Control-Allow-Credentials: true, and Access-Control-Allow-Origin cannot be the wildcard. It must name the exact origin.

This is the single most common credentialed-CORS failure, and the browser error message doesn't make it obvious. If you're moving token storage to cookies, expect to hit this — echo back the specific Origin from an allowlist rather than reflecting it blindly, since reflecting any origin defeats the protection entirely.

CORS is not a server-side control

CORS is enforced by browsers, on responses, to protect users. It is not access control. curl, a server-side fetch, and any non-browser client ignore it completely.

So a CORS header never authorizes anything — your API still needs real authentication and authorization on every endpoint. Treat CORS as a browser convenience, not a security boundary.

Frequently asked questions

Because CORS is a browser-enforced policy and curl ignores it. The request is reaching your server fine; the browser is refusing to expose the response to your JavaScript because the required Access-Control-Allow-* headers are missing.

The spec forbids it. If Access-Control-Allow-Credentials is true, Access-Control-Allow-Origin must name a specific origin rather than *. Otherwise any site could make credentialed requests to your API on a logged-in user's behalf.

Any method other than GET, HEAD, or POST; any Content-Type outside form encodings and text/plain; or any request header outside the CORS-safelisted set. An Authorization header is not safelisted, so authenticated requests almost always preflight.

Yes — Access-Control-Max-Age tells the browser how long to reuse a preflight result, in seconds. Browsers cap it (Chrome at 2 hours, Firefox at 24). Setting it removes an extra round trip from every authenticated request.

No. It protects browser users from having their credentials used by other sites. It provides no protection against direct requests from any non-browser client. Authentication and authorization on the server are what protect your API.

Next steps

Related tools

In the docs

All developer tools

CORS errors are usually a config problem

Allowed origins, callbacks, and logout URLs are set per application — so your local, staging, and production origins all just work.

Start free Configure allowed origins

Free, unlimited users. No credit card required.