CORS: what the browser blocks and what it does not

What it is

By default a script on origin A cannot read responses from origin B. The server on B opts in with Access-Control-Allow-Origin (a specific origin or *), and for requests with custom headers or non-simple methods the browser first sends an OPTIONS preflight that the server must answer with the allowed methods and headers. Credentials (cookies) require an explicit origin and Access-Control-Allow-Credentials: true.

Why it matters

Getting CORS wrong either breaks legitimate front-ends or exposes authenticated responses to any site. It is also widely misunderstood: it is not access control for the API, since non-browser clients ignore it entirely.

How to apply

• Public read-only APIs meant for browser use may send Access-Control-Allow-Origin: *; never combine * with credentials.
• For authenticated browser clients, allow only the specific front-end origins and keep the list in configuration.
• Answer preflights quickly with Access-Control-Max-Age so that they are cached.
• Add Vary: Origin when the allowed origin is echoed dynamically.

Pitfalls

Reflecting any Origin header back with credentials allowed is equivalent to no protection. CORS headers on error responses are often forgotten, which hides the real error from the front-end. Server-side agents and command-line tools are unaffected by CORS altogether.