CORS

CORS (Cross-Origin Resource Sharing) is a browser-enforced mechanism that governs when JavaScript running on one origin (scheme + host + port) is allowed to read the response of an HTTP request made to a different origin. It's a controlled relaxation of the browser's default same-origin policy, defined as part of the WHATWG Fetch Standard (originally a W3C Recommendation).

How it works

By default, a browser lets a page send a cross-origin request but blocks JavaScript from reading the response unless the server opts in with CORS response headers — most importantly Access-Control-Allow-Origin, naming which origin(s) may read the response. For a "simple" request (GET/HEAD/POST with only a few allowed headers and content types), the browser sends the real request directly and just checks the response header. For anything more (custom headers, PUT/DELETE, non-form content types like application/json), the browser first sends an automatic preflight OPTIONS request asking the server what's allowed, and only proceeds with the real request if the server's answer permits it.

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

CORS is entirely a browser-side protection — it does nothing to stop a server-to-server request or a tool like curl from reading a cross-origin response, since neither enforces the same-origin policy in the first place.

Common pitfalls

• Access-Control-Allow-Origin: * (allow any origin) can't be combined with Access-Control-Allow-Credentials: true — browsers reject that combination, since it would let any site read credentialed responses.
• A missing CORS header produces a browser console error that looks like a network failure, which sends a lot of developers debugging the wrong layer (the request usually did reach the server and got a response — the browser just refused to hand it to JavaScript).
• Reflecting the request's Origin header back verbatim as Access-Control-Allow-Origin (to "support" every origin) defeats the purpose of CORS as an access control and should be paired with an actual allowlist check.
• CORS controls whether a browser can read a response — it is not a substitute for server-side authentication or authorization.

Related terms

• DNS — cross-origin, for CORS purposes, is determined by scheme + hostname + port, all of which ultimately trace back to how DNS resolves the hostname.
• JSON — the typical payload format for the cross-origin API responses CORS headers govern access to.

See also

• Tool: Nginx Reverse Proxy Generator — scaffold an Nginx reverse-proxy config for routing traffic to a backend, the kind of config where CORS response headers are typically added.