Cors Scanner

CORS is enforced by the browser, not the server

The request usually reaches the server and the server usually responds normally. The browser then inspects the response headers, finds the origin is not permitted, and refuses to hand the response to JavaScript. This is why a request that fails in the browser succeeds from curl or Postman, and why server logs show a perfectly ordinary 200 while the console shows an error. Nothing is broken on the server; the server simply has not granted permission.

The same-origin rule is stricter than it looks

Origin means scheme, host and port together. https://example.com and http://example.com are different origins. So are example.com and www.example.com, and localhost:3000 and localhost:8080. A great many CORS problems in development are a port difference nobody registered as an origin change.

Preflight requests and what triggers them

Simple requests go straight out. Anything else triggers an OPTIONS preflight first, and the browser only sends the real request if the preflight approves it. Custom headers such as Authorization or a Content-Type of application/json are the usual triggers. A server that handles GET and POST correctly but returns 404 or 405 for OPTIONS will fail every preflighted request, and this is the most common CORS misconfiguration by a wide margin.

Credentials change the rules entirely

When a request carries cookies or authentication headers, the server must return Access-Control-Allow-Credentials: true, and Access-Control-Allow-Origin may not be the wildcard. It must name the exact origin, which usually means echoing the request's Origin header back after validating it against an allow-list. Wildcard plus credentials is rejected by every browser, and the resulting error message rarely says so plainly.

Wildcards are a decision, not a default

Access-Control-Allow-Origin: * makes an endpoint readable by script on any site. That is correct for a public API and wrong for anything authenticated or internal. Echoing back whatever Origin arrives without checking it against a list is functionally the same as a wildcard while looking like a restriction, and it is a recurring finding in security reviews.

Errors JavaScript cannot see

A cross-origin response exposes only a short list of headers to script unless Access-Control-Expose-Headers names more. A failed request also gives JavaScript almost no detail, deliberately, so the browser console and the network tab are the only places the real cause appears. Reading the console message rather than the caught exception is usually the fastest route to the answer.