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.

Category: Security (also: Web Development)

Author: Atomic Glue Security Team

## 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.

## Related entries

• [CSP](atomicglue.co/glossary/csp-backend)
• [Security Headers](atomicglue.co/glossary/security-headers)
• [JWT](atomicglue.co/glossary/jwt-backend)

Last updated December 2024. Permalink: atomicglue.co/glossary/cors-security