CORS.
A bouncer who phones the other building first: “is this guest allowed to talk to you?” before a page calls another site.
By default, a web page can only freely talk to the site it came from. If a script on site A tries to call site B’s data, the browser steps in like a cautious bouncer: “you’re from a different building — let me check before I let this through.”
CORS is the agreed way for site B to say which outside sites are welcome. It is the browser protecting you, not the server being difficult — which is why a CORS error shows up in your console even when the server itself is perfectly fine.
- 1
A page from one site wants to call another site’s API — a different “origin.”
- Different building — hold on.2
Your browser is the bouncer: same-origin walks in; cross-origin gets a second look.
- Is this guest on the list?3
For risky calls, the browser phones ahead first (a “preflight”): is this allowed?
- Yes — they’re welcome.4
The other site answers with its guest list — which origins it allows.
- 5
On the list? The real request goes through and the data comes back.
- Blocked by CORS policy.6
Not on the list? The browser blocks it and logs a CORS error — even though the server was fine.
Why the browser, not the server
The rule lives in the browser to protect you, the logged-in user. Without it, any random site you visit could quietly fire requests at your bank using your session. CORS is the controlled exception: the only cross-site calls allowed are the ones the other site explicitly opted into.
Reading a CORS error
A CORS error almost never means the server crashed. It means the response came back without the header that says “this origin is allowed.” The fix is on the receiving server (add the allowed origin), not in your front-end code — front-end tweaks cannot grant a permission the server never gave.