CORS configuration checker

Which origins are allowed: the literal value of Access-Control-Allow-Origin on the responses actually received, whether that is a wildcard, a single echoed origin or a fixed hostname.

Whether credentials are allowed alongside it, which is where the one combination browsers reject outright appears.

Whether a response that echoes the request origin also sends Vary: Origin, without which any shared cache in front of the endpoint can serve the wrong origin's response.

How the preflight is answered: one OPTIONS request is sent, and the status plus the Access-Control-Allow-* headers that came back are recorded.

Public, unauthenticated data served with a wildcard origin and no credentials. That combination is legitimate and common, and it is not flagged.

Authenticated endpoints echoing one validated origin from an allow-list, with credentials enabled and Vary: Origin present.

OPTIONS answered with 204 and the allow-headers and allow-methods that match what the real request will send.

No difference between what the preflight promises and what the actual response permits — the mismatch is invisible until a browser refuses a call that worked in an API client.

A wildcard origin together with Access-Control-Allow-Credentials: true. Browsers reject this pairing, so the call fails no matter what the server intended, and its presence usually means the CORS layer was configured by trial and error.

An echoed origin with no Vary: Origin. Correct for every single request and wrong the moment a cache sits in front of it.

An origin echoed back without validation, which is a wildcard written the long way: any site that asks gets permission.

OPTIONS answered with 404 or 405, which breaks every cross-origin browser call to that endpoint while leaving direct calls working perfectly.

CORS headers are frequently produced in more than one place — a framework middleware, a reverse proxy, a CDN rule — and the value that reaches the browser is whichever one came last.

Reading a configuration file tells you what one of those layers intends. Requesting the endpoint tells you what all of them together produced.

That is also why an endpoint can behave differently in staging and production with identical application code: the extra layer only exists in front of one of them.

`api.cors.wildcard` reads the allow-origin policy really returned. `api.cors.credentials` detects the invalid wildcard-plus-credentials combination. `api.cors.vary` checks for Vary: Origin wherever the origin is echoed. `api.options.preflight` sends the single OPTIONS request and records the answer.

Only endpoints already discovered are tested, so this never widens the surface it examines.

After any change to a reverse proxy, a gateway or a CDN rule, since all three can add or overwrite CORS headers without the application knowing.

When a front end on a new hostname starts calling the API — a new origin is exactly the case an allow-list was not written for.

Before enabling credentials on an endpoint that previously served public data, which is the change that turns a harmless wildcard into a rejected combination.

After adding a cache in front of an endpoint that echoes origins, because that is the moment a missing Vary: Origin stops being theoretical.