CORS
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls how web pages from one origin can request resources from a different origin. It uses HTTP headers to define allowed cross-origin requests.
§ 1 Definition
CORS is a W3C standard that allows servers to relax the browser's same-origin policy. The same-origin policy prevents a web page from one origin (defined as scheme + host + port) from reading resources from another origin. This is a critical security boundary. CORS enables legitimate cross-origin requests by having the server return specific HTTP headers that tell the browser the request is allowed.
§ 2 How CORS Works
When a browser makes a cross-origin request, the browser adds an Origin header. The server responds with Access-Control-Allow-Origin indicating which origins are permitted. For complex requests (non-simple methods like PUT/DELETE, or requests with custom headers), the browser first sends a preflight OPTIONS request to check permissions before sending the actual request. The server must respond with appropriate CORS headers for the preflight to succeed.
§ 3 Common CORS Headers
Access-Control-Allow-Origin: specifies allowed origins (or * for any). Access-Control-Allow-Methods: lists permitted HTTP methods. Access-Control-Allow-Headers: lists permitted request headers. Access-Control-Allow-Credentials: whether to expose cookies/authorization headers. Access-Control-Max-Age: how long preflight results can be cached.
§ 4 Security Implications
CORS is enforced by the browser, not the server. Any server-side tool (curl, Postman, server-to-server) can make cross-origin requests regardless of CORS headers. CORS protects the browser's security model, not the API itself. API authentication should still be handled via tokens, API keys, or session cookies.
§ 5 Note
§ 6 Common questions
- Q. Does CORS protect my API from unauthorized access?
- A. No. CORS only controls browser behavior. Server-to-server, mobile apps, and API clients bypass CORS entirely. Use proper authentication (tokens, API keys) to secure your API.
- Q. Can I use * for Access-Control-Allow-Origin in production?
- A. Only if your API is fully public and does not use credentials (cookies, Authorization headers). If you need credentialed requests, you must specify exact origins.
- Q. Why does my API work in Postman but not in the browser?
- A. Postman does not enforce CORS. Browsers do. Your API is likely missing the CORS headers.
- CORS is a browser-enforced mechanism, not server-side access control.
- Preflight requests (OPTIONS) verify permissions before actual requests.
- Avoid wildcard * in production with credentials.
- CORS does not replace API authentication.
Atomic Glue configures CORS for every API project at deploy time, enforces origin whitelists rather than wildcards, and validates header configurations in CI/CD. Get in touch.
Get in touchCORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls how web pages from one origin can request resources from a different origin. It uses HTTP headers to define allowed cross-origin requests.
Definition
CORS is a W3C standard that allows servers to relax the browser's same-origin policy. The same-origin policy prevents a web page from one origin (defined as scheme + host + port) from reading resources from another origin. This is a critical security boundary. CORS enables legitimate cross-origin requests by having the server return specific HTTP headers that tell the browser the request is allowed.
How CORS Works
When a browser makes a cross-origin request, the browser adds an Origin header. The server responds with Access-Control-Allow-Origin indicating which origins are permitted. For complex requests (non-simple methods like PUT/DELETE, or requests with custom headers), the browser first sends a preflight OPTIONS request to check permissions before sending the actual request. The server must respond with appropriate CORS headers for the preflight to succeed.
Common CORS Headers
Access-Control-Allow-Origin: specifies allowed origins (or * for any). Access-Control-Allow-Methods: lists permitted HTTP methods. Access-Control-Allow-Headers: lists permitted request headers. Access-Control-Allow-Credentials: whether to expose cookies/authorization headers. Access-Control-Max-Age: how long preflight results can be cached.
Security Implications
CORS is enforced by the browser, not the server. Any server-side tool (curl, Postman, server-to-server) can make cross-origin requests regardless of CORS headers. CORS protects the browser's security model, not the API itself. API authentication should still be handled via tokens, API keys, or session cookies.
Note
CORS errors are among the most common issues developers face when building SPA-frontend + API-backend setups. The error message 'No Access-Control-Allow-Origin header is present' means the server did not include the header in its response.
Common questions
Q: Does CORS protect my API from unauthorized access?
A: No. CORS only controls browser behavior. Server-to-server, mobile apps, and API clients bypass CORS entirely. Use proper authentication (tokens, API keys) to secure your API.
Q: Can I use * for Access-Control-Allow-Origin in production?
A: Only if your API is fully public and does not use credentials (cookies, Authorization headers). If you need credentialed requests, you must specify exact origins.
Q: Why does my API work in Postman but not in the browser?
A: Postman does not enforce CORS. Browsers do. Your API is likely missing the CORS headers.
Key takeaways:
CORS is a browser-enforced mechanism, not server-side access control.
Preflight requests (OPTIONS) verify permissions before actual requests.
Avoid wildcard * in production with credentials.
CORS does not replace API authentication.