CORS is one of the most misunderstood parts of web security because it sits close to access control without actually being access control.
It tells the browser whether frontend code from one origin is allowed to read a response from another origin. That is useful. It is not the same thing as deciding whether the request should be allowed in the first place.
What CORS Does
CORS mainly affects browser behavior:
- can the request be made normally?
- does it trigger a preflight?
- can the response be exposed to frontend JavaScript?
That is why a server can still receive a request even if the browser later blocks access to the response data.
That is also why CORS does nothing for non-browser clients like curl, backend services, or mobile apps. Those clients are not enforcing browser-origin rules in the first place.
What It Does Not Do
CORS does not replace:
- authentication
- authorization
- CSRF protection
- server-side validation
If your only protection is “the browser will block it because of CORS,” the design is not secure enough.
A Concrete Example
This header setup may be correct for a browser app:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
But the actual API still needs to validate whether the caller is authenticated and allowed to perform the action. CORS does not answer that question for you.
Further Reading