Why CORS Exists in the Browser
Browsers enforce the same-origin policy to prevent malicious websites from reading sensitive data from other domains. CORS relaxes this restriction in a controlled way by letting servers declare which origins, methods, and headers are permitted. Without CORS headers, any cross-origin fetch or XMLHttpRequest will be blocked, even if the server processed the request successfully.
Understanding CORS Headers
The Access-Control-Allow-Origin header specifies trusted origins. Access-Control-Allow-Methods lists permitted HTTP methods such as GET, POST, and DELETE. Access-Control-Allow-Headers declares which custom request headers are accepted. Access-Control-Expose-Headers controls which response headers the browser can read, and Access-Control-Max-Age caches preflight results to reduce latency.
Simple vs Preflight Requests
Simple requests use GET, HEAD, or POST with standard content types and skip the preflight step. Any request using other methods, custom headers, or non-standard content types triggers a preflight OPTIONS call. The server must respond to the preflight with the correct CORS headers before the browser sends the actual request, making proper configuration essential for API functionality.
Common Pitfalls and Best Practices
Avoid using wildcard origins in production; whitelist specific domains instead. Never combine wildcard origins with credentials because browsers will reject the response. Set a reasonable Max Age to reduce preflight overhead without caching stale policies. Always test CORS from the actual client origin because server-side tools bypass browser enforcement entirely.
