What Is CORS and Why Do Browsers Enforce It?

CORS Explainer

Cross-Origin Resource Sharing, or CORS, is an HTTP-based system that lets a server grant browser scripts limited access across the same-origin boundary. A page can often send or embed certain cross-origin resources, but the same-origin policy normally prevents its JavaScript from reading an arbitrary response. CORS adds response headers that tell the browser which requesting origins, methods, headers, and credentials the server is willing to expose. The browser enforces that decision; CORS is not a network firewall and does not stop nonbrowser clients from making requests.

For a simple cross-origin request, the browser includes an `Origin` header identifying the caller. The server may reply with `Access-Control-Allow-Origin` naming that origin or, for noncredentialed public data, a wildcard. If the response permission matches, the browser exposes the response to the calling script. If it does not, the network exchange may still occur, but JavaScript receives a CORS error rather than the protected response data. The server must therefore enforce authorization independently because CORS failure is not evidence that no request reached it.

Requests outside a limited set first trigger a preflight. The browser sends an `OPTIONS` request describing the intended method and non-simple request headers. The server answers with allowed origins, methods, and headers, and may specify how long the browser may cache that permission. Only after a successful preflight does the browser send the actual request. This check protects older servers from being surprised by script-generated methods or headers they never expected to receive cross-origin, but it adds a round trip that APIs may notice.

Credentials require tighter rules. Cookies or HTTP authentication are included only when the client opts into credentials and the server allows them. A credentialed response cannot use the wildcard origin; the server must return a specific permitted origin and allow credentials. When a server dynamically reflects approved origins, it should validate against an exact allowlist and make caches aware that the response varies by Origin. Blindly reflecting any value while accepting credentials can give an attacker’s page access to a user’s authenticated data.

CORS also distinguishes response headers that scripts may read from those that remain hidden. Servers can expose additional safe headers explicitly. Redirects, private network access, cached preflights, service workers, and opaque responses add practical complexity, so browser developer tools may show an error whose root cause is a missing header on an intermediate or error response. The requested server must return CORS headers; adding headers only to the calling page does nothing.

CORS does not replace CSRF protection, authentication, or input validation. A state-changing request may be possible through a form even when CORS blocks reading its response, and a valid CORS permission says nothing about whether the caller should be authorized as a user. APIs should define a narrow origin allowlist, permit only necessary methods and headers, avoid credentials for public resources, return consistent headers on errors, and test preflight behavior through real browsers. The useful mental model is permission to read, not permission to reach. CORS gives a server a standardized way to tell browsers when a script from another origin may inspect a response, while the rest of the application’s security rules still decide what the request is allowed to do.

Caching can create subtle exposure if responses for different callers are mixed. When an origin-specific decision changes the `Access-Control-Allow-Origin` value, shared caches need a suitable `Vary: Origin` signal or another strategy that keeps variants separate. Preflight caching is distinct from ordinary response caching and is bounded by browser policy even when the server advertises a long duration. Teams should include redirects, authentication failures, rate-limit responses, and unexpected methods in tests because these paths often omit headers applied only to successful API responses. Consistency makes browser failures diagnosable and prevents security from depending on an untested edge case.