CORS Test — Whether the Browser Will Allow the Call
This tests how a server responds to cross-origin requests, including the preflight exchange browsers perform before certain calls. Cross-origin rules are enforced by the browser, not the server, which produces the defining symptom: a request that works from a command line and is blocked in a browser.
Why run it
That asymmetry is why this check exists. From an operator's side the server is answering correctly and the logs show a successful request, while the client sees a failure — so the two parties looking at the problem see contradictory evidence. Testing the actual headers, including the preflight response, settles it. The frequent finding is that a proxy or CDN in front of the application strips or fails to forward the cross-origin headers the application correctly set.
Why automate it
Cross-origin configuration is fragile in a specific way: it depends on the exact set of origins allowed, and that list is edited whenever a new front-end is deployed or a domain changes. Because the failure appears in someone else's browser rather than your monitoring, the feedback loop is a support ticket. Scheduling a check from the origins that matter means the break is detected on deployment rather than reported by a customer, and it protects against an edge configuration change silently removing headers the application still sends.
What it gives you
Resolution for a failure where the server logs and the client experience disagree, which is otherwise a slow argument. Monitored, it catches the edge stripping headers the application is setting correctly.