I have a small frontend calling an API I control. Locally, the frontend runs on one localhost port and the API on another and the browser request succeeds. Once I deploy the frontend, the same request is blocked by CORS.
The API response in production includes an `Access-Control-Allow-Origin` header, but I noticed it is set to the old staging domain. The preflight response is also coming back from a proxy in front of the app, which is making me wonder whether I have two layers trying to manage the same headers.
I can make the immediate error disappear by allowing every origin, but I do not want to solve a configuration mistake with `*`. The API is meant for this one browser app plus a command-line script. There are no cookies involved; the web app sends an authorization header.
My understanding is that I should explicitly allow the production web origin, make sure `OPTIONS` requests reach a response that includes the expected headers, and leave non-browser clients out of the CORS discussion because they do not enforce it. I also need to check that the proxy is not overwriting what the API sends.
Is that the right mental model? I am especially interested in the debugging order here. CORS errors are good at making three different configuration problems look like the same red line in the console.