Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder

Cross-Origin Resource Sharing (CORS)

The browser mechanism that controls cross-origin requests — universally misunderstood as an error to disable, actually a security boundary to configure correctly.

What is CORS?

CORS (Cross-Origin Resource Sharing) is how a server tells the browser which other origins may read its responses. By default the browser enforces the same-origin policy — a page at app.example.com can’t read responses from api.other.com — and CORS is the controlled relaxation: the server sends Access-Control-Allow-Origin and related headers to opt specific origins in. The single most important thing to understand: CORS is enforced by the browser, protecting the user, not the server — which is why it confuses everyone.

Why it’s so misunderstood

CORS surfaces as an error (“blocked by CORS policy”), so developers experience it as an obstacle and reach for the worst fix: Access-Control-Allow-Origin: *, disabling the protection to make the error stop. But the error is the browser doing its job — preventing a malicious site the user visits from reading responses from an authenticated API the user is logged into. Two clarifications dissolve most confusion. First, CORS doesn’t protect your server — non-browser clients (curl, mobile apps, servers) ignore it entirely; it only governs what browser JavaScript on other origins can read, so it’s a protection for your users, not an access control for your API (that’s auth’s job). Second, the preflight OPTIONS request (the browser asking permission before non-simple requests) is normal, not a bug — though it adds a round trip worth caching via Access-Control-Max-Age.

Configuring it correctly

The right posture: allowlist specific trusted origins, never * for anything credentialed (browsers actually forbid * combined with Access-Control-Allow-Credentials, a safety rail people fight instead of heed). Reflect origins only from a validated allowlist — the dangerous anti-pattern is echoing back any Origin header, which effectively disables the protection while looking configured. Scope allowed methods and headers to what’s actually needed.

What people get wrong

  • Access-Control-Allow-Origin: * to “fix” the error — disabling a user-protection boundary rather than allowlisting real origins.
  • Reflecting arbitrary origins from the request — configured-looking, actually wide open.
  • Thinking CORS secures the API — it constrains browser JS only; curl and servers bypass it, so real access control must live in auth.

Primary source: MDN — Cross-Origin Resource Sharing

Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.