A cross-origin API request can reach its destination, execute application code, and produce a valid response even when the browser refuses to expose that response to JavaScript. That distinction is central to Cross-Origin Resource Sharing, yet it is often blurred by configurations that treat CORS as a connectivity switch.
CORS is a browser-enforced extension to the same-origin model. It gives a server a way to state which external origins may access selected responses from browser script. The server still owns authentication and authorization for the underlying resource. CORS controls an additional boundary: whether code running under another web origin may receive the response through browser APIs.
That boundary becomes security-sensitive as soon as an application accepts credentials, exposes private data, or allows origins outside its own administrative control.
The Origin header carries a security claim
For a cross-origin browser request, the Origin header identifies the requesting origin. A server can compare that value with an explicit policy and, when access is permitted, return an Access-Control-Allow-Origin header containing the accepted origin.
The comparison sounds simple, but origin syntax is exact. An origin consists of a scheme, host, and port. https://portal.example.com is distinct from http://portal.example.com, and a non-default port creates another origin. Paths are not part of an origin.
A robust policy therefore works from parsed, canonical origin values or exact entries generated from trusted configuration. Loose string tests are risky. A suffix check intended to accept example.com can accidentally admit an attacker-controlled hostname such as notexample.com. A substring test can fail in even more ways because it does not model hostname boundaries at all.
Reflection is another common failure mode. A server that copies any incoming Origin value into Access-Control-Allow-Origin has not implemented an allowlist; it has delegated the decision to the requester. If the same endpoint returns sensitive information, browser script from an attacker-controlled origin may become able to read it.
Credentials raise the consequence of a permissive policy
Cross-origin requests do not automatically gain unrestricted access to ambient browser credentials. Fetch and XMLHttpRequest apply credential rules, and servers that intend to permit credentialed CORS access must opt into it with Access-Control-Allow-Credentials: true.
When credentials are involved, the allowed-origin decision carries much more weight. A permitted origin may be able to issue requests in the context of a signed-in user and read responses that contain account data or other protected material, subject to cookie attributes and the application’s authentication design.
Browsers do not permit the wildcard * as Access-Control-Allow-Origin for a credentialed CORS response. Applications that need credentialed access for several origins commonly validate the request origin against an allowlist and return that specific origin when accepted.
This pattern is safe only when the allowlist itself represents a real trust decision. A broad rule covering every customer-controlled subdomain, every preview deployment, or every site under a shared hosting boundary can grant response access to principals that were never meant to receive it.
Origin ownership also changes over time. A hostname that was controlled when it entered an allowlist can later be abandoned, delegated, or repurposed. CORS policy is therefore inventory as much as configuration: accepted origins need an owner and a reason to remain trusted.
Preflight is negotiation, not authentication
Some cross-origin requests trigger a CORS preflight. The browser sends an OPTIONS request containing the intended method and, when relevant, requested header names. The server replies with the methods, headers, and origin policy it permits.
Preflight reduces the chance that browser script can silently send certain cross-origin operations to a server that never agreed to receive them. It does not establish the identity of a user, prove that a caller is benign, or replace authorization on the eventual request.
This matters for systems that treat the presence of a successful preflight as evidence that a request is trusted. The browser is enforcing a policy supplied by the server. An attacker can still send network requests outside a browser, where CORS enforcement does not apply. Every protected endpoint still needs its normal authentication and authorization controls.
The inverse is also important: not every cross-origin request receives a preflight. Requests meeting the browser’s criteria for CORS-safelisted methods, headers, and content types can be sent directly. A design that depends on OPTIONS as a universal gate is built on a false assumption.
Read access and request delivery are different properties
CORS primarily governs whether browser script can access a cross-origin response. It should not be treated as a general mechanism for preventing requests from reaching a server.
A state-changing endpoint can still require protection against cross-site request forgery when it relies on browser-managed credentials. Cookie SameSite attributes can reduce exposure, and anti-forgery tokens or equivalent request-binding controls remain relevant where cross-site submission is possible.
This separation explains a recurring operational surprise. A team removes an origin from its CORS allowlist and expects requests from that site to disappear from server logs. Requests may still arrive. The browser can block script from reading the response while the server has already processed the request.
For read-only endpoints, the distinction can be equally significant. A missing CORS permission can stop a browser application from consuming a response, but it does not make a publicly reachable API private. Non-browser clients are not constrained by the browser’s same-origin policy.
Caches can turn a correct decision into the wrong response
Dynamic origin reflection has a less obvious interaction with shared caches. Suppose an endpoint accepts two trusted origins and returns the matching Access-Control-Allow-Origin value. If an intermediary caches the first response without varying on Origin, it may serve that response to a request from the other origin.
The resulting behavior can be a functional failure, a data exposure issue, or both, depending on what else the cache key contains and whether personalized responses are cacheable. A response whose representation changes according to the request origin should normally communicate that variance, commonly with Vary: Origin, while the surrounding cache policy must also account for authentication and other response dimensions.
Vary is not a substitute for sound cache design. It tells compliant caches that the named request header affects representation selection. It cannot repair a system that caches private responses under an unsafe key or ignores response metadata.
CORS and caching therefore meet at a shared architectural boundary. The application makes an origin-specific access decision, but every intermediary that reuses the resulting response must preserve the dimensions that made that decision valid.
The null origin deserves an explicit decision
Browsers can serialize some origins as null, including certain sandboxed documents and other opaque-origin contexts. Treating the literal value null as harmless because it does not resemble a normal hostname can create an unintended permission.
An application should allow null only when its product behavior specifically requires access from opaque origins and the associated risk has been assessed. It should not appear as a fallback entry added to silence browser errors.
The same principle applies to development origins. http://localhost entries are convenient during local work, but production policy should not inherit them without a concrete need. A browser on a user’s machine can interact with local services in ways that differ sharply from server-to-server traffic, so local origin permissions deserve deliberate treatment.
Policy belongs close to the resource
Large platforms often centralize CORS at a reverse proxy or API gateway. Centralization can improve consistency, but only when the gateway has enough context to express the resource’s actual trust policy.
A single permissive rule applied to every route can erase distinctions between public assets, authenticated account APIs, administrative endpoints, and partner integrations. Conversely, independently generated CORS headers from both a gateway and an application can produce duplicate or contradictory values that browsers reject.
The useful abstraction is not “enable CORS for the API.” It is a mapping between resources, accepted origins, allowed methods and headers, credential requirements, and cache behavior. That mapping should be narrow enough to review and stable enough to test.
Telemetry can support that review. Rejected origins, unexpected preflight methods, and changes in the set of active allowed origins can reveal stale integrations or policy drift. Logging should avoid turning arbitrary origin strings into trusted structured data, but the decision itself is valuable security context.
CORS is most reliable when treated as an explicit delegation of browser response access. The server names the origins that may cross that boundary, browsers enforce the declaration for script, and the application retains its ordinary controls beneath it. Problems appear when any of those roles are assumed to provide guarantees they were not designed to provide.