Cross-Origin Resource Sharing (CORS) is the mechanism by which a web browser lets a page from one origin make requests to a server on a different origin in a controlled way. Browsers enforce a same-origin policy that, by default, prevents scripts on one site from reading responses from another site, a rule that protects users but also blocks the legitimate cross-origin API calls that modern web applications depend on. CORS provides a standardized way for a server to opt in, telling the browser through HTTP response headers which other origins are permitted to read its responses.
CORS is defined in the WHATWG Fetch standard, which contains a dedicated CORS protocol section establishing the request and response headers, header syntax, and the interaction between CORS and credentials. The central response header is Access-Control-Allow-Origin, which names the origin allowed to read a response. Other headers such as Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Expose-Headers, and Access-Control-Allow-Credentials further describe what the cross-origin caller may do and see.
A key part of the protocol is the preflight request. For requests that could have side effects or that use non-simple methods or headers, the browser first sends an automatic OPTIONS request carrying Access-Control-Request-Method and Access-Control-Request-Headers. The server answers with the matching Access-Control-Allow headers, and only if that response approves the actual request does the browser proceed to send it. The Fetch standard also defines a CORS-preflight cache so that repeated calls need not re-run the check each time, governed by the Access-Control-Max-Age header.
The Fetch standard distinguishes CORS-safelisted request headers, a small set including Accept, Accept-Language, and certain Content-Type values, which do not by themselves trigger a preflight. This is why a simple cross-origin GET often succeeds without an OPTIONS round trip, while a JSON POST with a custom header does not. Understanding this safelist is central to reasoning about when a browser will and will not preflight a request.
CORS replaced earlier, more fragile workarounds for cross-origin data access such as JSONP, giving the web a principled model rooted in the server’s explicit consent. As single-page applications and browser-based clients increasingly consumed APIs hosted on separate domains and content delivery networks, CORS became an everyday concern for API developers, who must configure their servers to emit the correct Access-Control headers or watch their front-end requests fail in the browser even when the underlying HTTP call succeeds.