What defines an 'origin'? What does the same-origin policy block, and how does CORS selectively relax it? Explain preflight requests.
Whether you understand that CORS is server-granted permission, not a client bypass.
An ORIGIN is the triple (scheme, host, port) — https://app.com and http://app.com differ (scheme), as do app.com:443 and app.com:8080 (port). The SAME-ORIGIN POLICY is a browser security rule: script from one origin can send requests to another, but by default cannot READ the cross-origin response, and can't touch another origin's DOM or cookies. It's what stops a malicious site from reading your bank's responses using your session. CORS (Cross-Origin Resource Sharing) is how a SERVER opts in to sharing: it returns Access-Control-Allow-Origin (a specific origin or *) plus optional -Allow-Methods/-Allow-Headers/-Allow-Credentials, and the browser only exposes the response to JS if those headers permit it. Crucially CORS is enforced by the browser and granted by the server — you cannot disable it from client code. 'Simple' requests (GET/POST/HEAD with safe headers and standard content types) go straight through and are checked on the response. Anything else (PUT/DELETE, custom headers, application/json) triggers a PREFLIGHT: the browser first sends an OPTIONS request asking permission; only if the server approves does the real request go. With credentials (cookies), Allow-Origin cannot be * and Allow-Credentials must be true. The server always RECEIVES the request — CORS only gates whether JS may read the reply.
Debugging 'blocked by CORS policy' errors: the fix is server headers, not client code; watch for the OPTIONS preflight.
origin = scheme + host + port (https://app.com:443)
Preflight (for non-simple requests):
Browser → OPTIONS /api Origin: https://app.com
Access-Control-Request-Method: PUT
Server → Access-Control-Allow-Origin: https://app.com
Access-Control-Allow-Methods: PUT
→ approved, browser sends the real PUT
With cookies: Allow-Origin must be exact (not *) AND Allow-Credentials: true