Question presented to candidate: "If a server sends back an Access-Control-Allow-Origin header that doesn't match the requesting page's origin, who actually blocks the request — the server, or something else? Where does that blocking genuinely happen?"
What a strong answer should cover:
- 📌 Interview term: CORS (Cross-Origin Resource Sharing) — a browser-enforced security mechanism restricting whether a web page running at one origin can read the response from a request made to a DIFFERENT origin — a real, deliberate relaxation of the browser's stricter same-origin policy, opted into explicitly by the SERVER via response headers.
- 📌 Interview term: the real, direct answer to the prompt — verified directly: making the identical cross-origin-style request from Node (not a browser) against a real local server sending a mismatched
Access-Control-Allow-Originheader genuinely succeeded — Node's ownfetchimplementation does not enforce CORS at all, confirming CORS blocking is enforced specifically by the BROWSER's own fetch/XHR implementation, never by the server and never by Node itself. - 📌 Interview term:
Access-Control-Allow-Origin— the response header a server sends to explicitly grant permission — verified directly, reading the real header value a server sent; the SERVER only ever suggests permission via this header, it never itself performs any blocking. - 📌 Interview term: simple requests vs. preflighted requests — a "simple" request (a plain GET/POST with only a few allowed headers) is sent directly; anything else (custom headers, other HTTP methods, certain content types) triggers a real, automatic preflight — the browser sends a separate
OPTIONSrequest first, checking permission BEFORE sending the actual request at all. - A precise answer names that CORS is fundamentally a browser security feature protecting the USER, not a mechanism protecting the server — a non-browser client (curl, Node's own fetch, a mobile app) can genuinely make the identical cross-origin request with no CORS restriction whatsoever, verified directly.
Clarifying questions expected:
- None — this is a definitional/technical question; directly answering WHO enforces CORS (the browser, not the server) is the strong signal, since it is the single most commonly misunderstood aspect.
Code / implementation expected: Optional — demonstrating that a non-browser client (this very verification script) is genuinely unaffected by a mismatched CORS header is the clearest way to isolate exactly what CORS does and does not do.