Cybersecurity glossary
What is Cross-Origin Resource Sharing (CORS)?
Learn what Cross-Origin Resource Sharing (CORS) is, how browsers use Access-Control headers and preflight requests, common misconfigurations, and how to allow cross-origin access safely.
Definition
Cross-Origin Resource Sharing (CORS) is a browser mechanism that allows servers to opt in to controlled cross-origin reads by web applications, using HTTP response headers to relax the default same-origin restrictions on reading responses.
Why CORS exists
The same-origin policy stops a page on https://a.example from reading responses from https://api.b.example by default. That protection is essential. It is also inconvenient for legitimate architectures where a frontend and API live on different origins.
Cross-Origin Resource Sharing (CORS) is the standardized opt-in. Servers declare which external browser origins may read responses, which methods and headers are allowed, and whether credentialed requests are permitted. Browsers enforce those declarations before exposing response bodies to JavaScript.
How CORS works
Frontend makes a cross-origin request
JavaScript on one origin calls an API hosted on another scheme, host, or port.
Browser classifies the request
Some requests are 'simple'; others trigger a preflight OPTIONS check first.
Server returns Access-Control headers
Responses include allowlists for origins, methods, headers, and optionally credentials.
Browser compares policy to the page origin
If the page’s Origin is permitted, JavaScript may read the response; otherwise access is blocked.
Credentials require explicit opt-in
Cookies or Authorization in credentialed mode need Allow-Credentials and a non-wildcard origin.
Non-browser clients ignore CORS
Server-side and native clients are unaffected; authentication and authorization must still stand alone.
Key headers
Access-Control-Allow-Origin
States which origin may read the response, either a specific origin or * for non-credentialed public data.
Access-Control-Allow-Methods
Lists methods permitted after preflight, such as GET, POST, PUT, and DELETE.
Access-Control-Allow-Headers
Lists request headers the browser may send in the actual cross-origin call.
Access-Control-Allow-Credentials
When true, permits credentialed mode. Must not be paired with a wildcard Allow-Origin.
Simple requests vs preflights
Browsers skip preflight for a narrow set of simple methods and headers. Other combinations—custom headers, uncommon content types, or certain methods—trigger OPTIONS first. Servers that ignore OPTIONS break legitimate SPAs even when GET/POST handlers are correct.
Dangerous misconfigurations
| Pattern | Risk |
|---|---|
| Reflect any Origin + Allow-Credentials: true | Malicious sites can read authenticated victim responses in the browser. |
| Null origin allowed broadly | Sandboxed or local contexts may become unexpected trusted origins. |
| Overly broad regex allowlists | attacker.example.com.evil.tld style bypasses when matching is sloppy. |
| Assuming CORS equals access control | APIs remain callable directly without browser enforcement. |
Secure CORS checklist
- Allow only explicit, trusted frontend origins for credentialed APIs.
- Never combine Access-Control-Allow-Origin: * with Allow-Credentials: true.
- Validate Origin against a strict allowlist; do not trust substring matches.
- Handle OPTIONS preflights intentionally with least-privilege methods and headers.
- Keep authorization server-side on every request; CORS is not authentication.
- Prefer token designs that avoid relying on cross-origin cookie credentialed calls when practical.
- Log and alert on unexpected Origin values hitting authenticated endpoints.
- Test with a malicious page origin to ensure responses are not readable.
Practical architecture notes
Many teams avoid credentialed CORS entirely by using same-site reverse proxies or issuing bearer tokens to first-party frontends. When credentialed cross-origin calls are required, treat the origin allowlist as a security boundary equal to cookie scope.
Remember that “CORS error” in DevTools often hides an underlying 500 or auth failure: the browser suppresses body access, which confuses debugging. Inspect the raw network response status and headers carefully.
The practical takeaway
CORS lets servers opt into controlled cross-origin response reads inside browsers. It is a compatibility bridge across the same-origin policy—not a substitute for authentication, authorization, or CSRF protections.
Configure allowlists tightly, treat credentialed mode as high risk, and assume attackers can call your API outside the browser regardless of CORS headers.
Related security terms
Same-Origin Policy (SOP)
The default browser rule CORS selectively relaxes for opted-in cross-origin reads.
Cross-Origin Embedder Policy (COEP)
A separate policy that may require CORS or CORP opt-in for embedded resources.
Content Security Policy (CSP)
Controls which origins may load as scripts or other content types, distinct from CORS reads.
Cross-Site Request Forgery (CSRF)
Cross-site request abuse that CORS alone does not prevent for simple cookie-bearing requests.
Frequently asked questions
What is CORS in simple terms?
CORS is how a server tells a browser that a web page from another origin is allowed to read its response. Without that permission, the browser blocks JavaScript on the other origin from inspecting the response.
Does CORS protect servers from requests?
No. CORS is enforced by browsers, not by arbitrary clients. Attackers can still call APIs with curl or serverside code. CORS controls whether trusted web pages can read responses in a victim’s browser.
What is a CORS preflight?
A preflight is an OPTIONS request the browser sends before certain cross-origin requests to ask whether the actual method, headers, and credentials are allowed. The server answers with Access-Control-* headers.
What is a dangerous CORS misconfiguration?
Reflecting arbitrary Origin values with Access-Control-Allow-Credentials: true is a classic flaw. It can let a malicious website read authenticated responses from a victim’s browser session.
Is Access-Control-Allow-Origin: * always unsafe?
Wildcard origins can be acceptable for truly public responses. They must not be combined with credentialed access. Sensitive authenticated APIs need explicit origin allowlists.
How does CORS relate to CSRF?
CORS can block JS from reading responses, but simple cross-site requests may still be sent and cause state changes. CSRF defenses remain necessary for cookie-authenticated actions.
Do mobile apps use CORS?
Native apps and backend services are not browsers and do not enforce CORS. Browser-based frontends do. Design API auth assuming non-browser clients exist.
References
Explore authoritative guidance and frameworks related to cross-origin resource sharing (cors).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.