CORS (Cross-Origin Resource Sharing)
About 4 min read
Last updated: 2026-03-15
What Is CORS (Cross-Origin Resource Sharing)
CORS (Cross-Origin Resource Sharing) is an HTTP header-based mechanism that safely relaxes the browser's same-origin policy to enable resource sharing between different origins. An origin is defined by the combination of three elements: scheme (http/https), hostname, and port number.
The same-origin policy is a browser security mechanism that restricts scripts loaded from one origin from accessing resources at another origin. Without this restriction, a malicious site could use the user's browser to call the API of a banking site where the user is logged in.
However, in modern web applications, it is common for the frontend and backend API to operate on different domains. CORS enables necessary cross-origin communication safely by having the server explicitly declare which origins are allowed access via HTTP response headers.
How CORS Works
CORS operates in two modes depending on the type of request.
Simple Requests
Requests using GET, HEAD, or POST (limited to certain Content-Types) without custom headers are treated as "simple requests." The browser sends the request as-is and checks the Access-Control-Allow-Origin header in the response. If the origin is allowed, the response is passed to JavaScript; otherwise, it is blocked.
Preflight Requests
For requests that do not meet simple request conditions - such as PUT, DELETE, or requests with custom headers - the browser sends a "preflight request" using the OPTIONS method before the actual request. The server responds with headers specifying the allowed conditions.
Access-Control-Allow-Origin: Allowed originsAccess-Control-Allow-Methods: Allowed HTTP methodsAccess-Control-Allow-Headers: Allowed request headersAccess-Control-Max-Age: Cache duration for preflight results (seconds)
If the preflight response meets the allowed conditions, the browser sends the actual request.
Requests with Credentials
Cross-origin requests that include cookies or authentication headers require Access-Control-Allow-Credentials: true. In this case, Access-Control-Allow-Origin cannot use a wildcard (*) and must specify a concrete origin.
Common Misconfigurations and Security Risks
CORS misconfigurations can nullify the protection provided by the same-origin policy, creating serious security risks.
- Careless use of
Access-Control-Allow-Origin: *: Allowing all origins makes the API accessible from any site. Should not be used for anything other than public APIs. Must never be used for APIs that handle credentials - Reflecting the Origin header without validation: Reflecting the request's Origin header value directly in
Access-Control-Allow-Originis effectively the same as a wildcard. Validate against a whitelist - Allowing the null origin: Allowing
Access-Control-Allow-Origin: nullenables access from sandboxed iframes and local files, which can be exploited for attacks - Overly permissive subdomain matching: When allowing patterns like
*.example.com, if an attacker can take over a subdomain, they can exploit CORS
CORS misconfigurations can amplify damage when combined with XSS or CSRF.
Best Practices for Safe CORS Configuration
Guidelines for configuring CORS safely.
- Manage allowed origins with a whitelist: Maintain a list of allowed origins in environment variables or configuration files, and validate against the request's Origin header with exact matching
- Allow only the minimum necessary methods and headers: List only what is actually used in
Access-Control-Allow-MethodsandAccess-Control-Allow-Headers - Leverage preflight caching: Set
Access-Control-Max-Ageappropriately to reduce preflight request frequency and improve performance - Handle requests with credentials carefully: When setting
Access-Control-Allow-Credentials: true, strictly limit allowed origins - Combine with CSP and security headers: Build defense in depth by combining CORS with other security headers
- Assume HTTPS: Do not include HTTP origins in the allow list. Prevents origin spoofing through man-in-the-middle attacks
CORS is a browser-side control and does not apply to server-to-server communication or command-line tool requests. Do not rely solely on CORS - always implement server-side authentication and authorization.
To learn more about this topic, see HTTP Security Headers: 5 Essential Headers to Protect Your Website.
Common Misconceptions
- CORS is a security feature that protects the server
- CORS is a browser-side control and does not directly protect the server. CORS restrictions do not apply to curl or server-to-server communication. CORS is a mechanism that protects browser users and operates at a different layer than server-side authentication and authorization.
- If you get a CORS error, just use a wildcard (*) to fix it
- A wildcard allows access from all origins, posing a high security risk. It cannot be used with requests that include credentials. The correct approach is to add only the necessary origins to a whitelist.