/kɔːrz/
n. “You may speak… but only from where I recognize you.”
CORS, short for Cross-Origin Resource Sharing, is a browser-enforced security model that controls how web pages are allowed to request resources from origins other than their own. It exists because the web learned, the hard way, that letting any site freely read responses from any other site was a catastrophically bad idea.
By default, browsers follow the same-origin policy. A script loaded from one origin — defined by scheme, host, and port — is not allowed to read responses from another. This rule prevents malicious websites from silently reading private data from places like banking portals, email providers, or internal dashboards. Without it, the browser would be an accomplice.
CORS is the controlled exception to that rule. It allows servers to explicitly declare which external origins are permitted to access their resources, and under what conditions. The browser enforces these declarations. The server does not trust the client. The client does not trust itself. The browser acts as the bouncer.
This control is expressed through HTTP response headers. When a browser makes a cross-origin request, it looks for permission signals in the response. If the headers say access is allowed, the browser hands the response to the requesting script. If not, the browser blocks it — even though the network request itself may have succeeded.
One of the most misunderstood aspects of CORS is that it is not a server-side security feature. Servers will happily send responses to anyone who asks. CORS determines whether the browser is allowed to expose that response to JavaScript. This distinction matters. CORS protects users, not servers.
Requests come in two broad flavors: simple and non-simple. Simple requests use safe HTTP methods and headers and are sent directly. Non-simple requests trigger a preflight — an automatic OPTIONS request sent by the browser to ask the server whether the real request is permitted. This preflight advertises the method and headers that will be used, and waits for approval.
The preflight mechanism exists to prevent side effects. Without it, a malicious page could trigger destructive actions on another origin using methods like PUT or DELETE without ever reading the response. CORS forces the server to opt in before the browser allows those requests to proceed.
Credentials complicate everything. Cookies, HTTP authentication, and client certificates are powerful — and dangerous. CORS requires explicit permission for credentialed requests, and forbids wildcard origins when credentials are involved. This prevents a server from accidentally granting authenticated access to the entire internet.
CORS is often confused with CSP, but they solve different problems. CSP restricts what a page is allowed to load or execute. CORS restricts what a page is allowed to read. One controls inbound behavior. The other controls outbound trust.
Many modern APIs exist entirely because of CORS. Without it, browser-based applications could not safely consume third-party services. With it, APIs can be shared selectively, documented clearly, and revoked instantly by changing headers rather than code.
CORS does not stop attackers from sending requests. It stops browsers from handing attackers the answers. In the security world, that distinction is everything.
When developers complain that CORS is “blocking their request,” what it is actually blocking is their assumption. The browser is asking a simple question: did the other side agree to this conversation? If the answer is no, the browser walks away.
CORS is not optional. It is the price of a web that allows interaction without surrendering isolation — and the reason your browser can talk to many places without betraying you to all of them.