What It Actually Means
By default the browser refuses. Without that default, any site you visited could quietly issue requests to your bank, your email or your company systems using your logged-in session, and read the answers. The restriction is one of the load-bearing protections of the web.
CORS is the controlled exception: a way for a server to say which other origins it is willing to accept calls from.
Why You Hear About It
You hear about it because it produces an error at the worst moment, usually when two things your business owns are being connected.
The pattern is familiar: the site is at one address, the API is at another, someone connects them, and the browser blocks the call with a message about the origin not being allowed. Nothing is broken. The server is fine, the API is fine, and the browser is doing its job.
It matters to you for one reason. The quickest fix is to allow every origin, and it works instantly, which makes it very tempting under deadline pressure.
Why The Quick Fix Is A Problem
Allowing all origins means any website can call that API from a visitor’s browser. If the API is entirely public data, that is harmless and sometimes intended.
If it is behind a login, it is a real exposure, because the browser will attach the user’s session to those calls. A malicious page can then make requests as your logged-in user and read the responses. This is the specific attack the default prevents, and the wildcard setting removes it.
The correct fix is barely more work: list the origins that should be permitted. It takes a few minutes and it is a configuration line rather than a project.
What To Ask
- Do any of our APIs allow all origins? If yes, is that API genuinely public, with no session behind it?
- Was this set deliberately or to clear an error? The honest answer is often the second, and it is worth revisiting.
- Which origins do we actually need? Usually two or three, all known.
The Thing To Understand About It
CORS protects your users’ browsers. It is not a protection on your API.
Anything outside a browser ignores it entirely: a script, a command-line tool, another server. CORS headers are instructions to browsers, and only browsers honour them. So a locked-down CORS policy does not make an API private, and an open one does not make it insecure for non-browser callers, because they were never restricted in the first place.
That distinction matters when a supplier describes CORS as securing an endpoint. It does not. Authentication and authorisation secure an endpoint. CORS decides which web pages may call it on a user’s behalf, which is a different question with a different answer.
More terms are in the glossary.
