Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls whether a web page running on one origin (domain, protocol, and port) is allowed to make requests to a server on a different origin, and if so, what parts of the response the requesting page’s JavaScript is permitted to read.

The Problem It Addresses

Browsers enforce a default security rule called the same-origin policy, which prevents a script running on one website from reading data returned by requests to a different website — a critical protection against a malicious site silently reading a user’s private data from another site they happen to be logged into. But legitimate cross-origin requests are extremely common in modern web architecture — a frontend hosted on app.example.com calling an API hosted on api.example.com is technically cross-origin, since the subdomains differ. CORS provides a controlled way for a server to explicitly opt in to allowing specific cross-origin requests, rather than the same-origin policy blocking all of them unconditionally.

How It Works

When a browser makes a cross-origin request, it includes an Origin header identifying where the request came from. The server’s response includes CORS headers (most importantly Access-Control-Allow-Origin) specifying which origins are permitted to read the response. For requests beyond simple GET requests — like those using custom headers or methods like PUT and DELETE — the browser first sends an automatic “preflight” OPTIONS request to check whether the actual request would be allowed, before sending the real request at all.

Common Misconceptions

CORS is enforced entirely by the browser, not the server — it doesn’t prevent a server from receiving a cross-origin request, only from that request’s response being readable by the requesting page’s JavaScript, which is why CORS misconfigurations (like a poorly considered wildcard Access-Control-Allow-Origin: * on an endpoint returning sensitive, user-specific data) are a genuine security risk, but CORS is not itself a substitute for server-side authentication and authorization.

CORS in API Design

For teams building a public or partner-facing API, CORS configuration is a deliberate design decision rather than an afterthought: an API intended to be called directly from browser-based JavaScript on other domains needs explicit, carefully scoped CORS headers, while an API intended only to be called from a trusted backend server (where CORS doesn’t apply, since it’s a browser-enforced mechanism, not a server-to-server one) doesn’t need permissive CORS configuration at all. A common mistake is configuring an overly permissive CORS policy (Access-Control-Allow-Origin: *) out of convenience during development and never tightening it before shipping to production, needlessly widening the set of origins that can read potentially sensitive API responses.