CORS Tester — Decode the Error That Blocks Your Fetch
Cross-origin rules are enforced by the browser, not by the server. That single fact explains the defining symptom: a request that succeeds from a terminal and fails from your page, with a console message that describes the rule rather than the cause. This tests the actual headers, including the preflight request the browser sends before certain calls.
When it helps
Because the console error is misleading in a specific way. It says the server did not return the right header, which sounds like the server is at fault, when the usual reality is one of a few well-defined mistakes: a wildcard origin combined with credentials, which the specification forbids; a custom header your code adds that is not in the allowed list, silently turning a simple request into a preflighted one; or a proxy stripping headers the application set correctly.
Worth running automatically
The allowed-origin list is edited whenever a front end is deployed to a new domain, a preview environment is created, or a domain changes. Because the failure appears in a user's browser rather than in your logs, the feedback loop is a bug report — often days later, often from someone who cannot reproduce it consistently. A scheduled check from the origins that matter turns that into an alert at deploy time, and it also catches an edge configuration silently removing headers your application still sends.
What you get out of it
Translates a misleading console message into the actual misconfiguration, which is rarely the one the message names. Scheduled, it moves discovery from a customer bug report days later to the moment the deploy landed, when the change that caused it is still obvious.