Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) is the browser mechanism that decides whether JavaScript running on one origin is allowed to read a response from an API on another origin. It works by relaxing the browser’s same-origin policy through a set of Access-Control-* HTTP headers the server returns, and it is specified as part of the WHATWG Fetch standard rather than a standalone RFC. Practically, CORS is the difference between an API a web app can call directly and one it cannot.

• Access-Control-Allow-Origin - The header where a server names the origins it trusts to read its responses, or * to allow any.
• Preflight requests - For non-simple requests the browser first sends an HTTP OPTIONS call to confirm the method and headers are permitted before the real request goes out.
• Allowed methods and headers - Access-Control-Allow-Methods and Access-Control-Allow-Headers spell out exactly what a cross-origin caller may send.
• Credentialed requests - Access-Control-Allow-Credentials controls whether cookies and auth headers ride along, and it cannot be combined with a wildcard origin.

In real API operations CORS configuration is a governance surface I check constantly, because it sits precisely between usability and exposure. A too-permissive * policy on an authenticated endpoint leaks data to any site a user visits, while a too-strict one quietly breaks every browser-based integration and single-page app. Getting it right is a small but telling signal of how well a provider understands who is actually calling their HTTP API from the open web.