What Is CORS?
The Same-Origin Policy and Why Browsers Enforce It
What is CORS? Cross-Origin Resource Sharing, or CORS, is a browser mechanism that lets a server say which other websites may read its responses. It exists because browsers, by default, block scripts on one website from reading responses that come from a different website.
Two addresses are the same origin only if their scheme, host and port all match. For example, https://example.com and https://shop.example.com are different origins, and so are https://example.com and http://example.com. The same-origin policy is the default rule that stops a script from one origin from reading data returned by another.
Without this rule, a script on an unrelated page could ask your bank's site for account details and read the reply, using the cookies your browser already holds for that bank. The policy prevents that. It is worth knowing what it does not block: browsers still let pages send many cross-origin requests, such as image loads and form submissions. The main restriction is on reading the response.
CORS is the controlled exception. A server that wants a cross-origin page to read its responses adds specific headers to say so.
How Preflight Requests and CORS Headers Work
For some requests, the browser first sends a preflight request. This is an OPTIONS request that asks the server whether the real request is allowed, using the method and headers the page wants to send, such as a PUT or DELETE method. The server answers with CORS headers, and the browser sends the real request only if the answer permits it.
The most important header is Access-Control-Allow-Origin, which names the origin allowed to read the response, or uses a wildcard for any origin. Other headers list the methods, request headers and cache duration that the server accepts.
Credentials need extra care. When a request includes cookies or HTTP authentication, the server must name a specific origin rather than a wildcard, and it must explicitly allow credentials. Browsers enforce this so that a wildcard cannot expose logged-in data to any site.
Two points often confuse developers. First, CORS is enforced by the browser, not by the server. A command-line tool or a server-to-server call ignores CORS entirely, which is why an API can work in a testing tool and still fail in a web page. Second, a passing CORS check says nothing about whether the caller is authorized to see the data.
Why an API Works in a Tool but Not in a Web Page
A team builds a dashboard on app.example.com that loads usage figures from api.example.com. During testing, the API responds correctly in a command-line tool and in an API testing client, so the team assumes the API is fine.
When the dashboard runs in a browser, the figures never appear. The browser console shows that a cross-origin request was blocked because the response lacked the expected CORS header. The API itself is working. Only the browser applies the rule, so the same request succeeds everywhere except the place where the data is displayed.
The lesson is that CORS problems concern the relationship between two origins inside a browser. They are best understood by looking at the browser console and the response headers, not only at the output of the API.
Frequently asked questions
Is CORS a security feature or a bug?
CORS is a security feature. It is a controlled relaxation of the same-origin policy: the server decides which other origins may read its responses, and the browser enforces that decision. Problems usually arise when a server allows too many origins, or when developers loosen CORS rules to make an error disappear without understanding why it appeared.
Does CORS protect an API from unauthorized access?
No. CORS only controls whether a browser script can read a response from another origin. It does not stop someone from sending requests with a command-line tool, and it does not check who the caller is. An API still needs its own authentication and authorization. The wider threats are covered in API security risks.