Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls how web pages can request resources from a domain different from the one that served the page. It is a formal extension of the same-origin policy, the foundational rule that prevents a script running on one origin from freely accessing data on another.
Understanding Origins and Why They Matter
In web security, an "origin" is defined by the combination of a protocol (such as https), a domain (such as example.com), and a port number. Two URLs share the same origin only when all three components match exactly. A page loaded from https://app.example.com and an API hosted at https://api.example.com are considered different origins, even though they share the same root domain. Without a mechanism to explicitly permit such cross-origin requests, browsers block them by default to protect users from malicious scripts silently harvesting data across sites.
How CORS Works
CORS works through a set of HTTP headers exchanged between the browser and the server. When a browser detects that a request will cross an origin boundary, it includes an Origin header in the request, declaring where the request is coming from. The server then responds with headers such as Access-Control-Allow-Origin, which explicitly lists the origins permitted to read the response. If the server's response does not include the appropriate headers, the browser silently blocks the response before the requesting JavaScript code can access it. The error is enforced client-side, meaning the server did receive and process the request, but the browser refuses to expose the result.
For certain types of requests, such as those using HTTP methods like PUT or DELETE, or those carrying custom headers, browsers first send a lightweight preflight request using the OPTIONS method. This preflight asks the server whether the actual request will be allowed, and only proceeds if the server confirms permission. This two-step handshake prevents unintended side effects from cross-origin calls.
CORS in REST API Integrations
CORS errors are among the most common obstacles developers encounter when building applications that consume REST APIs. A frontend application hosted on one domain calling an API on another will trigger CORS checks on every request. The fix almost always lives on the server side: the API must be configured to return the correct Access-Control-Allow-Origin and related security headers. Developers cannot resolve a CORS error purely from the browser or frontend code, which is a frequent source of confusion.
CORS configuration requires care. Setting Access-Control-Allow-Origin to a wildcard (*) permits any origin to access a resource, which is acceptable for fully public APIs but inappropriate for endpoints handling authenticated or sensitive data. In those cases, servers should explicitly whitelist trusted origins and pair the policy with proper credential handling using the Access-Control-Allow-Credentials header.