Browser security boundaries
CORS, authentication and CSRF: separate boundaries
Why can access be denied after a successful preflight?
Understand the concept
CORS controls whether browser script may read another origin’s response. It is not general access control for curl or backend clients. A preflight asks whether a method and headers are allowed; it does not perform the protected data operation. Successful preflight does not authenticate or authorise the subsequent request.
Credentialed requests involve client credentials settings, cookie rules and server origin policy together. A wildcard origin is not suitable for credentialed response sharing. Avoid uncontrolled origin reflection. Cookie-authenticated state changes still require appropriate CSRF protection; CORS is not a universal CSRF defence.
Inspect both the server response and CORS metadata when browser code cannot read an error. Login redirects can break OPTIONS handling. Apply relevant CORS policy to failures too, but remember that browser response visibility never grants resource ownership or permission.
When diagnosing CORS and 401 behaviour in Next.js browser requests.
Treating an origin allowlist as user or resource authorisation.
One topic. Three levels of depth.
OPTIONS preflight allowed
GET actual request → 401Preflight does not authenticate.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
curl can call the API without CORS response fields. Is that a bug?
Show the solution and explanation
No: CORS is enforced by browsers, not a universal firewall.No. The API must enforce its own authentication and authorisation.