Lesson 8 of 30

CORS & the Same-Origin Policy

Q: A teammate says 'the server is blocking our request with a CORS error.' Is that accurate? Explain what's actually happening and how you'd fix it.

A strong answer covers: The same-origin policy is a browser default; CORS headers are how a server opts back in for specific origins; CORS is enforced by the browser withholding the response from JS, not by the server refusing the request — correcting the common misconception; Fix is server-side: add/correct Access-Control-Allow-Origin (and understand preflight OPTIONS requests for non-simple requests).

The browser blocks your own JavaScript from reading responses from a different origin by default — CORS is the server's explicit permission slip that opts back in, selectively.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A cross-origin request fails with a CORS error in the browser console. Did the server ever actually receive and process the request?

Usually yes — CORS blocks the browser from handing the response to your JS, not the request from reaching the serverNo — the browser prevents the request from ever leaving the machineNo — CORS is enforced by the server refusing to accept the connection

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on CORS & the Same-Origin Policy

What interviewers actually ask about this, and what a strong answer has to cover.

A teammate says 'the server is blocking our request with a CORS error.' Is that accurate? Explain what's actually happening and how you'd fix it.

A strong answer covers

The same-origin policy is a browser default; CORS headers are how a server opts back in for specific origins
CORS is enforced by the browser withholding the response from JS, not by the server refusing the request — correcting the common misconception
Fix is server-side: add/correct Access-Control-Allow-Origin (and understand preflight OPTIONS requests for non-simple requests)

Likely follow-ups

What is a preflight request, and what triggers the browser to send one?
Why can't Access-Control-Allow-Origin: * be combined with credentialed requests?
Does a non-browser HTTP client (like curl) need to worry about CORS at all?

Practice these with the AI interviewer →

The plain-language idea

The same-origin policy is a browser security default: JavaScript running on https://app.com cannot read the response of a request to https://api.other.com unless that other server explicitly allows it. "Origin" means the exact combination of scheme + host + port — https://app.com and http://app.com are different origins; so are app.com and api.app.com.

CORS (Cross-Origin Resource Sharing) is the server opting back in, via response headers:

Access-Control-Allow-Origin: https://app.com

Without this header (or the wrong value), the browser still lets the request go out and the server still processes it — but the browser blocks your JavaScript from reading the response. This is a common point of confusion: CORS is not a firewall stopping the request; it's the browser withholding the response from your code.

CORS: the browser polices what your page is allowed to readStep 1 of 3

fetch('https://api.other-site.com') from your page — the browser blocks the response by default. Different origin.

What people usually miss

Watch out

CORS is enforced by the browser, not the server. A server has no way to "block" a cross-origin request from happening — it can only tell the browser, via headers, whether to hand the response to the calling script. A non-browser client (curl, another server) ignores CORS entirely, because CORS is a browser-specific protection.
Access-Control-Allow-Origin: * can't be combined with credentials (cookies, Authorization headers) — sending credentials cross-origin requires an exact origin match in the header, not a wildcard, for real security reasons (a wildcard plus credentials would let any site read authenticated responses).
A CORS error in the console is a client-side symptom of a server-side configuration gap — the fix is almost always adding/correcting Access-Control-Allow-Origin on the server, not anything the frontend code can work around on its own (short of a proxy).

Why this matters in interviews

"Why am I getting a CORS error, and what actually causes it?" is one of the most common real debugging questions frontend developers hit — correctly explaining that it's the browser withholding the response, not the server refusing the request, is the precise distinction that separates understanding from guessing.