Files
What you'll learn
- Explain the same-origin policy and what CORS changes: a browser rule, lifted by the server's headers, that never stops a non-browser client
- Enable CORS on a Nest app for a list of origins, with the methods, headers, credentials and preflight cache the front end needs
- Read a preflight request and its answer, and tell it from the actual request
- Say why a refused origin still gets a 200 body and no Access-Control headers, and why '*' and credentials cannot be combined
Press Run tests to start the app. Its log appears here.Graded endpoints
The Origin header names an allowed site, so the answer carries Access-Control-Allow-Origin naming it back, Allow-Credentials, and Vary: Origin so a cache keeps answers per origin
The regular expression matches admin.shelter.example; the header echoes the exact origin, never the pattern
The server still answers 200 with the body; it just grants nothing, and it is the browser on evil.example that refuses to show the page the result
No Origin header, no CORS: a server-to-server call or a curl needs no permission and gets no headers
The browser asks first: may this origin POST here with these headers? An empty 204 lists the allowed methods and headers, and Max-Age lets the browser skip asking again for ten minutes
Answered, but with no permissions in it, so the browser never sends the real request
The real request after a preflight; a POST with a JSON body carries the same origin headers as a GET
Authorization was allowed in the preflight, so the browser sends it; the guard reads it as always
CORS headers ride on error responses too, or the page could not even read the status
Staff add a cat from the admin page
Public, and answered to anyone; the headers decide only what a browser may show
DELETE is in the allowed methods; a 204 carries the origin header like any response