Explain the Same-Origin Policy and CORS.

The Same-Origin Policy (SOP) is the foundational security boundary of the web. Without it, any site you visit could silently read your logged-in webmail, bank, or admin console using your own cookies. SOP stops that.

The Same-Origin Policy

An origin is the triple of scheme + host + port (https://app.example.com:443). SOP says script running in one origin generally cannot read the response of a request to a different origin. Note the nuance: the browser will often still send the cross-origin request (which is exactly why CSRF exists), but it blocks the script from reading the result. This is what keeps a malicious page from harvesting data from your authenticated sessions elsewhere.

Why CORS exists

SOP is deliberately strict, but legitimate apps constantly need cross-origin data — a front-end on app.example.com calling an API on api.example.com. Cross-Origin Resource Sharing (CORS) is the mechanism by which the server opts in to sharing. It loosens SOP in a controlled way; it does not turn it off.

How CORS works

The browser adds an Origin header; the server responds with Access-Control-Allow-Origin naming the origins allowed to read the response. For requests that can change state or use non-simple headers/methods, the browser first sends a preflight OPTIONS request, and the server must approve the method and headers via Access-Control-Allow-Methods / -Headers before the real request is sent.

The common security mistake

To send cookies cross-origin you must set Access-Control-Allow-Credentials: true — and in that case the spec forbids the wildcard Access-Control-Allow-Origin: *; you must echo a specific origin. Naively reflecting the request's Origin back with credentials enabled is a classic misconfiguration that lets any site read authenticated responses.

Interviewers look for the scheme/host/port definition, the "blocks reading, not sending" subtlety, CORS as a server opt-in that relaxes (not disables) SOP, and the credentials-plus-wildcard pitfall.