Detailed explanation
CORS, or Cross-Origin Resource Sharing, is an HTTP-header-based mechanism that lets a server permit browser JavaScript to access responses from another origin. An origin is the combination of scheme, hostname, and port: https://app.example.com and https://api.example.com are different origins. Browsers normally restrict this access through the same-origin policy; CORS provides controlled exceptions. It matters when a frontend calls an API hosted on a different origin, a common arrangement in web applications.
For a cross-origin fetch, the browser sends an Origin header, and the server can respond with Access-Control-Allow-Origin: https://app.example.com. The browser checks that permission before exposing the response to JavaScript. A mismatch or missing permission causes the fetch to fail from the script’s perspective, even if the server received and processed the request. CORS is enforced by browsers, not by curl or ordinary server-to-server HTTP clients. It is therefore not authentication, authorisation, or protection against callers directly accessing an endpoint.
Some requests, often called simple requests, are sent without a preflight when their method, headers, and content type meet CORS safelist requirements. For example, an ordinary GET usually qualifies, while a POST using application/json generally does not. For a non-safelisted request, the browser first sends an OPTIONS preflight containing Origin, Access-Control-Request-Method, and, when needed, Access-Control-Request-Headers. The server advertises permissions using headers such as Access-Control-Allow-Methods: GET, POST and Access-Control-Allow-Headers: Content-Type. If the preflight succeeds, the browser sends the actual request, whose response must also satisfy CORS checks.
For cross-origin cookies, fetch generally needs credentials: 'include', while the server must return Access-Control-Allow-Credentials: true and an explicit allowed origin rather than *. Cookie rules such as SameSite and browser third-party-cookie restrictions still apply. Access-Control-Expose-Headers makes additional response headers readable by JavaScript. Interviewers usually judge whether you distinguish the same-origin policy from CORS, understand preflight versus actual requests, and recognise that CORS cannot replace access control or CSRF protection.
Key points to remember
- An origin consists of scheme, hostname, and port; a different path alone does not change it.
- CORS lets servers declare cross-origin permissions that browsers enforce.
- Non-safelisted methods, headers, or content types generally trigger an OPTIONS preflight.
- Credentialed requests require an explicit allowed origin and Access-Control-Allow-Credentials: true.
- CORS controls browser-script access to responses, not general access to the server.
Common mistakes candidates make
- Adding Access-Control-Allow-Origin to the frontend request instead of configuring it on server responses.
- Assuming every CORS failure means the browser never sent the actual request.
- Using mode: 'no-cors' as a fix and expecting JavaScript to read the resulting opaque response.
Likely follow-up questions
Why does an API work in curl but fail in browser fetch?
curl does not enforce the browser’s same-origin policy or CORS checks. Inspect the browser’s Network panel to determine whether the preflight failed or the actual response lacked the required CORS headers.
Does Access-Control-Allow-Methods: GET, POST mean those methods always require a preflight?
No; the request’s method, headers, and content type determine whether preflight is required. Access-Control-Allow-Methods declares method permissions during preflight; it does not trigger preflight itself.
How should a server allow several trusted frontend origins?
Validate the request’s Origin against an allowlist and return the matching origin in Access-Control-Allow-Origin, rather than a comma-separated list. When responses vary by origin, also send Vary: Origin so caches distinguish them correctly.
Interview tip: Define CORS, walk through a frontend-to-API request and its possible preflight, then clearly state that it is not an authentication mechanism.