CORS

CORS is a browser security mechanism that controls whether a web page loaded from one domain is allowed to request resources from a different domain. By default, browsers enforce a strict rule called the same-origin policy, which stops a page on one site from freely reading data from another site. That rule prevents a malicious page from quietly making requests to your bank on your behalf and reading the response. CORS is the controlled, standardized way to relax that restriction when it is safe and intended, letting a server declare which other origins are permitted to access its resources.

Mechanically, CORS works through a conversation of HTTP headers between the browser and the server. When a page tries to request data from a different origin, the browser includes information about where the request is coming from, and the server responds with headers that state which origins it allows, which request methods are permitted, and which headers may be used. If the server's response approves the requesting origin, the browser lets the page read the result; if not, the browser blocks it and the request fails. For certain requests that could change data, the browser first sends a small preliminary "preflight" request to ask the server for permission before sending the real one. Crucially, CORS is enforced by the browser, not by the server on its own, and it protects users rather than the server's data directly.

The abbreviation stands for cross-origin resource sharing, and the mechanism was standardized by the W3C during the 2010s as web applications increasingly needed to pull data from APIs and services hosted on domains other than the one serving the page. As single-page applications and third-party APIs became normal, a safe, explicit way to permit cross-origin requests became essential.

For a business, CORS matters because modern websites routinely combine resources from many origins: a front-end on one domain talking to an API on another, embedded services, and third-party tools. Correct CORS configuration is what allows those legitimate integrations to work while keeping the browser's protections intact for users. When a company builds an API that its own web app or its partners' apps need to call from the browser, CORS settings determine who can do so. Get it right and everything connects smoothly; get it wrong and either legitimate features break or the door is opened too wide.

The nuances and common mistakes trip up many developers. The most frequent frustration is a blocked request that produces a confusing browser error, which usually means the server has not been configured to allow the requesting origin, a server-side fix rather than something the front-end can force. The most dangerous mistake goes the other way: configuring the server to allow all origins indiscriminately, which can expose sensitive endpoints to any website. CORS is also commonly misunderstood as a server-side firewall, when in fact it only instructs browsers and does not stop non-browser clients. CORS relates closely to API endpoints that receive cross-origin calls, to the fetch mechanism that makes those calls, to middleware where the permitting headers are often set, and to authentication that still must guard the data itself. Configured thoughtfully, CORS keeps cross-origin functionality both possible and safe.