Cross-origin resource sharing (CORS) is a security mechanism that controls whether JavaScript running in your web browser can access responses from a different origin.
CORS policies use special HTTP headers to determine whether a web application running at one address (origin) should be allowed to access resources from another address. This is critical for preventing unauthorized access to sensitive data.
How It Works
When a browser makes a request to a different origin (meaning a different scheme, host or port), it applies CORS rules before exposing the response to JavaScript.
1. Simple request check
For simple GET, HEAD or POST requests with basic headers, the browser may send the request directly. However, after receiving the response, the browser will block the calling page from reading it unless the server includes valid CORS headers, such as:
Access-Control-Allow-OriginAccess-Control-Allow-Credentials(if cookies or HTTP authentication credentials are used)
The server may process the request normally, but the browser can still hide the response entirely.
2. Preflight requests (OPTIONS)
For non-simple requests (such as those with custom headers, JSON content types or non-GET/POST/HEAD methods), the browser sends a preflight request first:
- The browser issues an
OPTIONSrequest asking what the server allows. - The server responds with CORS configuration specifying which origins, methods and headers are permitted.
If the preflight response doesn’t approve the planned request, the browser blocks the request before it is sent.
3. Enforcement happens in the browser
CORS is enforced entirely by the browser:
- Your backend may receive the request or be fully capable of responding.
- But if the CORS headers don’t match the browser’s expectations, the browser refuses to deliver the response to the JavaScript caller.
- This makes it seem like the API “failed,” even though the server may have responded correctly.
4. Not applicable to server-to-server calls
CORS is never enforced on server-to-server or service-to-service traffic.
Only browser-based environments (including web apps, extensions, embedded webviews and browser-based AI agents) apply CORS restrictions.
This separation is why CORS protects users from malicious websites but cannot verify whether a requesting workload or service is actually trustworthy.
Why This Matters for Modern Enterprises
As enterprises deploy hybrid architectures with frontend apps and AI agents spanning multiple domains, CORS configuration becomes a persistent friction point. A restrictive policy breaks legitimate services, while an overly permissive one creates serious security holes.
For example, your customer-facing web apps likely call internal APIs hosted on different cloud environments. Each one of those cross-origin requests requires explicit CORS approval. When teams deploy rapidly across dev, staging and production, maintaining consistent and secure CORS policies becomes operationally complex.
For organizations building AI-powered interfaces or deploying agentic systems that interact with browser-based tools, CORS configuration directly impacts deployment velocity. Teams often waste hours debugging failed API calls, only to find the issue was a simple missing CORS header rather than an authentication problem.
Properly configured CORS policies keep your APIs accessible to authorized clients while blocking requests that could lead to data theft or unauthorized actions.
Common Challenges With CORS
- Missing workload identity verification: CORS controls which origins can make requests but doesn’t verify whether the requesting workload is authorized or compromised.
- Credential handling complications: You must explicitly allow credentials and pair them with exact origins; wildcards won’t work. Without workload identity verification, your CORS policy remains vulnerable to compromised services.
- Overly permissive wildcard configurations expose your API to any website. This creates a major security gap when handling authentication tokens or sensitive data.
- Inconsistent policies across environments break legitimate integrations when overly strict production policies differ from permissive development settings.
- Preflight request failures block legitimate traffic when servers don’t handle OPTIONS requests correctly.
FAQ
You Have Questions?
We Have Answers.
Does CORS apply to server-to-server API calls?
No. CORS is a browser security mechanism that only applies when browsers make cross-origin requests. Server-to-server and machine-to-machine connections bypass browsers entirely, though they still require proper authentication and authorization.
What's the difference between CORS and authentication?
CORS controls which origins can make requests to your API at the browser level, while authentication verifies the actual identity of the client making the request. CORS prevents unauthorized websites from accessing your API through users’ browsers, but it can’t verify whether the requesting workload itself is legitimate or compromised.
How do CORS policies interact with API gateways?
API gateways typically handle CORS enforcement themselves by returning the appropriate CORS headers in response to preflight and actual requests. The browser sends requests to the gateway endpoint, and the gateway decides whether to include the headers that permit cross-origin access. If the gateway’s CORS configuration rejects the request, the browser blocks the response from reaching JavaScript. The gateway can also layer additional security, like rate limiting and authentication, on top of CORS.
Should I disable CORS for internal APIs?
CORS only applies to browser-based requests, so disabling it won’t affect server-to-server communication. However, if any browser-based tools or dashboards access your internal APIs, removing CORS protections exposes those endpoints to cross-origin attacks.