Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which websites can make requests to your web server from a different origin. An origin is defined by the combination of protocol, domain, and port. For example, https://app.example.com and https://api.example.com are different origins.
Without CORS, the browser's Same-Origin Policy would block all cross-origin requests. CORS relaxes this policy in a controlled way by letting servers specify which origins are allowed to access their resources.
When a browser makes a cross-origin request, it includes an Origin header identifying where the request came from. The server inspects this header and decides whether to allow the request by including specific response headers.
Simple requests (GET, POST with certain content types) are sent directly. The browser checks the response for an Access-Control-Allow-Origin header. If the requesting origin is listed (or the header is set to *), the browser allows the response through. If not, the browser blocks the response.
Preflight requests are used for more complex operations (PUT, DELETE, custom headers, JSON content type). Before sending the actual request, the browser sends an OPTIONS request asking the server what it allows. The server responds with headers indicating allowed methods, headers, and origins. Only if the preflight is approved does the browser send the real request.
Access-Control-Allow-Origin specifies which origins can access the resource. It can be a specific origin (https://app.example.com) or for any origin. You cannot use with credentialed requests.
Access-Control-Allow-Methods lists the HTTP methods (GET, POST, PUT, DELETE) the server permits for cross-origin requests.
Access-Control-Allow-Headers specifies which request headers are allowed beyond the default set.
Access-Control-Allow-Credentials indicates whether the browser should include cookies and authorization headers in cross-origin requests. When set to true, the Allow-Origin header must be a specific origin, not *.
Access-Control-Max-Age tells the browser how long (in seconds) to cache preflight responses, reducing the number of OPTIONS requests.
Reflecting the Origin header without validation is the most critical CORS mistake. Some developers configure their server to echo back whatever Origin the browser sends in the Allow-Origin response header. This effectively disables CORS protection because any website can make credentialed requests to your API.
Using a wildcard with credentials does not actually work (browsers block it), but attempting to work around it by reflecting origins creates the vulnerability described above.
Allowing null origins is dangerous because the null origin can be triggered from sandboxed iframes, local files, and certain redirect scenarios. Attackers can craft pages that send requests with a null origin to bypass CORS restrictions.
Overly broad origin patterns like allowing any subdomain (*.example.com) can be exploited if an attacker compromises or creates a subdomain (attacker.example.com).
Maintain an explicit allowlist of trusted origins. Check the request's Origin header against this list server-side, and only return the matching origin in the response. Reject requests from unlisted origins by not including CORS headers at all.
If your API is public and does not use cookies or authentication, using Access-Control-Allow-Origin: * without credentials is safe and appropriate.
For APIs that require authentication, always specify exact origins, enable the credentials header, and restrict allowed methods and headers to the minimum necessary.
Test your CORS configuration using browser developer tools or command-line tools like curl with custom Origin headers to verify that unauthorized origins are properly rejected.