CORS is a browser-enforced permission model. Debug it by understanding the origin, preflight request and response headers instead of adding wildcard headers randomly.
An origin is the combination of scheme, host and port. https://app.example.com and https://api.example.com are different origins. When browser JavaScript calls a different origin, the browser evaluates the CORS response before making the response available to your script.
The server may have returned data successfully and the browser may still block JavaScript from reading it. That is why the network tab matters.
For some cross-origin requests, the browser sends an OPTIONS request first. This preflight asks whether the real method and headers are allowed. If OPTIONS is routed through authentication middleware that rejects it, the real request may never be sent.
Inspect the OPTIONS response status and Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers values.
When cookies or browser credentials are involved, Access-Control-Allow-Origin cannot be a wildcard. The server must return the specific allowed origin and Access-Control-Allow-Credentials when appropriate. The client must also request credentials explicitly.
Do not solve a local development problem by allowing every origin in production. Maintain an allowlist for the applications that should be able to call the API from a browser.
CORS protects browser access; it does not stop servers, scripts or command-line clients from making requests. Your API still needs proper authentication and authorization. Treat CORS as one browser-facing policy, not a security boundary for all clients.