Browser security boundaries
SOP, CORS and preflight
Browser access policy is not API authorisation.
Understand the concept
The same-origin policy restricts script reads across origins. CORS permits specified browser reads; curl and server-side clients need not enforce it, so it is not authentication.
Some safelisted requests are sent without preflight. Blocking script access afterwards does not mean the server performed no action. JSON or Authorization commonly triggers an OPTIONS preflight, which does not carry credentials.
Credentialed access needs an approved explicit origin and credentials policy, not a wildcard. Validate reflected origins and vary caches by Origin. Cookie restrictions still apply. no-cors produces an opaque response rather than permission to read JSON.
Configure browser calls between Next.js and .NET correctly.
Assuming a CORS error proves no server-side action occurred.
One topic. Three levels of depth.
Origin: https://app.example.testThe browser’s request origin.
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.
Can CORS guarantee only your frontend calls an API?
Show the solution and explanation
CORS ≠ authentication / authorisationNo; authentication, resource authorisation and abuse controls are separate.