How Does Cross-Origin Resource Sharing Work?

Cross-Origin Resource Sharing Explainer

Cross-Origin Resource Sharing, or CORS, is the browser mechanism that lets a server decide which other origins may allow their scripts to read its responses. An origin is defined by a combination of scheme, host, and port, so https://shop.example and https://api.example are different origins even though they share a parent domain. Browsers normally apply the same-origin policy to keep a script from one site from freely reading private data returned by another. CORS adds an opt-in layer on top of HTTP: the destination server sends response headers that tell the browser whether sharing with the requesting origin is permitted.

Some cross-origin requests can be sent without a preliminary check when they use a limited set of methods, headers, and content types considered safelisted by the Fetch standard. The browser includes an Origin header, and the server may respond with an Access-Control-Allow-Origin value that matches the caller or with a wildcard when the rules permit it. The browser then decides whether the script may access the response. A CORS failure often appears to application code as an unreadable or blocked response even though the network request reached the server and the server generated a reply.

Requests outside the safelisted conditions normally trigger a preflight. The browser first sends an OPTIONS request that identifies the intended method and any non-safelisted request headers. The server answers with CORS headers describing the origins, methods, and headers it allows. Only after a satisfactory response does the browser send the actual request. A server can also state how long the preflight result may be cached, subject to browser limits. Preflights add work, but they keep a script from surprising a server with a more powerful cross-origin operation before the server has had a chance to opt in.

Credentials make the rules stricter. Cookies and HTTP authentication are not automatically exposed to every cross-origin request. Application code must request credentialed handling, and the server must explicitly allow credentials and name an allowed origin; a wildcard origin cannot be used for a credentialed response. When a server selects an origin dynamically, caches also need to distinguish responses by the Origin request header, commonly through the Vary header. Careless reflection of arbitrary origins, especially together with credentials, can expose private data to an attacker-controlled website.

CORS is frequently mistaken for authentication or a server-side firewall. It is neither. The browser enforces whether frontend JavaScript can read a response, but command-line tools, backend services, and hostile clients do not have to obey browser CORS rules. A request may also perform an action on the server even when the browser later blocks the script from reading the response. Servers still need authentication, authorization, input validation, and protections against cross-site request forgery where applicable. CORS should grant the narrowest origins, methods, headers, and credential behavior that the application actually requires.

For developers, debugging begins by identifying the exact requesting origin and determining whether the request is safelisted or preflighted. The browser’s network tools can show the Origin header, the OPTIONS exchange, and the response headers, while server logs can reveal redirects or errors that occurred before CORS headers were added. The important question is not simply whether cross-origin traffic exists, but whether this browser-delivered response should be readable by this origin under these conditions. Correctly configured, CORS supports web applications that use APIs, fonts, or other resources across origins without abandoning the same-origin policy that protects data in the browser. It also makes the sharing decision visible at the server boundary: developers can review which origins are trusted, remove obsolete partners, and test changes without weakening every request. Consistent handling on success and error responses matters because a missing header on an error can hide the real server problem behind a generic browser warning.