First, the Same-Origin Policy
CORS only makes sense once you understand the rule it relaxes. Browsers enforce the same-origin policy: a web page may freely talk to its own origin, but by default it cannot read responses from a different one. The reason is protective. You might be logged into your bank in one tab; without this rule, a malicious page in another tab could quietly make a request to the bank using your browser's session and read your balance. The same-origin policy slams that door — a script can only read data from the origin that served it.
An origin is more specific than a domain. It is the exact combination of three things — scheme, host, and port:
Compared to https://app.example.com | Same origin? | Why |
|---|---|---|
https://app.example.com/account | Yes | Scheme, host, and port all match (path is irrelevant) |
https://api.example.com | No | Different host |
http://app.example.com | No | Different scheme (http vs https) |
https://app.example.com:8443 | No | Different port |
This is why a front-end at app.example.com calling an API at api.example.com is a cross-origin request even though they are the same company — the host differs, so the browser treats them as strangers.
CORS Is the Controlled Exception
Modern sites legitimately need to make cross-origin requests all the time — a single-page app fetching from its API, a site pulling a font or a public dataset. CORS, Cross-Origin Resource Sharing, is the mechanism that lets a server opt in to being read by other origins. It works entirely through HTTP headers: the server being called includes an Access-Control-Allow-Origin header naming who is allowed, and the browser checks it before letting the calling page see the response.
Access-Control-Allow-Origin: https://app.example.comIf that header is present and names your origin (or uses the wildcard *), the browser hands your script the response. If it is absent or names a different origin, the browser blocks your script from reading it — and logs the CORS error. Crucially, the request may have reached the server and succeeded; CORS governs whether your page is allowed to read the result.
The Preflight Request
For straightforward reads — a plain GET with ordinary headers — the browser just makes the request and checks the response header afterwards. But for requests that could change data or carry unusual headers, the browser takes a cautious extra step first: the preflight.
Before sending the real request, the browser automatically fires an OPTIONS request asking permission. It is using the OPTIONS method to say: "I am about to send a PUT from this origin with these headers — will you allow it?" The server answers:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400Only if the answer permits the method and headers does the browser send the actual request. The Access-Control-Max-Age line lets the browser cache this permission so it need not preflight every single call. A request triggers a preflight when it uses a method beyond GET/POST/HEAD, sets custom headers, or sends a content type other than the basic form types — anything, in other words, that a simple HTML form could not have done on its own.
Reading a CORS Error Correctly
The single most useful thing to know about CORS is where the fix lives. A CORS error is the browser reporting that the server you called did not grant your origin permission. You cannot fix it by changing your front-end fetch code, and disabling it in the browser only masks it on your own machine. The remedy is on the server being called: it must return the appropriate Access-Control-Allow-* headers. If you do not control that server, you typically route the call through your own backend, which faces no same-origin restriction because the policy is a browser rule, not a network one.
That last point is also the key to what CORS does and does not protect. It guards users — stopping a hostile page from abusing a visitor's logged-in session elsewhere. It does nothing to stop direct requests from a command-line tool or a server, which simply ignore the headers. So CORS is never a substitute for real authentication; a server must still verify who is asking, regardless of origin.
CORS and Credentials
One more wrinkle catches people out. By default, cross-origin requests do not carry cookies or authentication. To include them, the front-end must explicitly opt in and the server must respond with Access-Control-Allow-Credentials: true — and when credentials are involved, the wildcard * is forbidden; the server must name the exact origin. This pairing exists so that a site cannot both throw its doors open to everyone and hand over a visitor's authenticated session at the same time. It is the same caution that runs through all of CORS: cross-origin reading is allowed, but only when both sides have clearly agreed to it.
Frequently Asked Questions
What is CORS?
Cross-Origin Resource Sharing — a browser mechanism that lets a server explicitly allow pages from other origins to read its responses. By default the same-origin policy blocks cross-site reads; CORS is the controlled exception, driven by the Access-Control headers the server sends.
What counts as a different origin?
An origin is the scheme, host, and port together. All three must match to be the same origin. So api.example.com differs from app.example.com (host), http differs from https (scheme), and even a different port is cross-origin.
What is a CORS preflight request?
For requests that could change data or carry unusual headers, the browser first sends an automatic OPTIONS request asking permission. The server replies with Allow-Origin, Allow-Methods, and Allow-Headers, and only then does the browser send the real request. Simple GETs usually skip it.
Why am I getting a CORS error?
Your page tried to read a response from another origin and that server did not return an Access-Control-Allow-Origin header permitting your origin. The fix is on the server being called, not in your front-end. Often the request actually succeeded — the browser simply blocked your script from reading the result.
Does CORS make a server more secure?
CORS protects users, not servers — it stops a malicious page from using a visitor's browser to read private data from another site they are logged into. Because only browsers enforce it, it does nothing against direct requests from other tools. Server-side authentication is still required.