Infrastructure

CORS

2014ActivePublished: 28 September 2026Updated: 28 September 2026Published

Key innovation

Introduced a header-based way for servers to safely and selectively relax the browser Same-Origin Policy, declaring which foreign origins may read their resources.

How it works

The browser attaches an Origin header to every cross-origin request. For simple requests — method GET, HEAD or POST, only safelisted headers, and for POST a Content-Type limited to application/x-www-form-urlencoded, multipart/form-data or text/plain — the browser sends the request immediately and then checks whether the response carries a matching Access-Control-Allow-Origin header; if not, it blocks script access to the response. For requests that are not simple (custom headers, other methods, other Content-Type, credentials: include mode) the browser first performs a preflight: an automatic OPTIONS request carrying Access-Control-Request-Method and Access-Control-Request-Headers. The server responds (usually 204) with Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers and optionally Access-Control-Max-Age (preflight cache lifetime). Only after approval is the actual request sent. For credentialed requests (cookies, HTTP auth) the server must return Access-Control-Allow-Credentials: true, and the wildcard "*" is then forbidden for Access-Control-Allow-Origin (and related headers) — an explicit origin must be given, otherwise the browser blocks the response. The Access-Control-Expose-Headers header lists which non-safelisted response headers the script may read.

Problem solved

The Same-Origin Policy blocks reading responses to cross-origin requests made from script, which would prevent legitimate applications (e.g. a frontend on one origin consuming an API on another) from communicating across domains. CORS solves this by letting the server explicitly and selectively grant access to chosen origins — without disabling the browser protection entirely.

Components

Origin (request header)Identifies the origin making the request

Header automatically added by the browser to cross-origin requests; indicates the scheme, host and port of the calling page.

Preflight request (OPTIONS)Prior permission negotiation before the actual request

Automatic OPTIONS request sent for non-simple requests, carrying Access-Control-Request-Method and Access-Control-Request-Headers; the server confirms whether the actual request is allowed.

Access-Control-Allow-OriginDeclares the allowed response origin

Response header indicating which origin may read the resource: a specific origin or "*"; "*" is forbidden for credentialed requests.

Access-Control-Allow-MethodsList of allowed HTTP methods

Preflight response header listing the HTTP methods allowed for the resource (e.g. GET, POST, OPTIONS).

Access-Control-Allow-HeadersList of allowed request headers

Preflight response header listing which headers (e.g. custom ones, Content-Type) may appear in the actual request.

Access-Control-Allow-CredentialsPermits sending credentials

Response header; value true allows including cookies and authentication data. Requires an explicit origin instead of "*".

Access-Control-Max-AgePreflight response cache lifetime

Response header specifying, in seconds, how long the browser may cache the preflight result, reducing the number of OPTIONS requests.

Access-Control-Expose-HeadersExposes response headers to script

Response header listing which non-safelisted headers JavaScript may read from the response.

Implementation

Reference implementations

cors (Express/Connect middleware)

JavaScript · expressjs

Implementation pitfalls

Wildcard "*" with credentialsCritical

When a request includes credentials (credentials: include) and the response has Access-Control-Allow-Origin: *, the browser blocks the response.

Fix:Return a specific origin (ideally validated against an allowlist) together with Access-Control-Allow-Credentials: true.

Missing preflight OPTIONS handlingHigh

The server does not correctly answer the automatic OPTIONS request, so the actual non-simple request is blocked.

Fix:Configure the server/API gateway to answer OPTIONS with Allow-Methods/Allow-Headers and a 2xx status.

Unsafe Origin reflectionCritical

Reflecting any Origin into Access-Control-Allow-Origin together with Allow-Credentials: true grants every origin access to resources with the user’s cookies.

Fix:Validate Origin against a strict allowlist before returning it; never reflect the value unchecked.

Non-exposed response headersMedium

Script cannot read non-safelisted response headers unless they are listed in Access-Control-Expose-Headers.

Fix:List the required headers in Access-Control-Expose-Headers.

Poorly chosen Access-Control-Max-AgeLow

Too short a preflight cache lifetime generates excess OPTIONS requests; browsers also impose their own upper caps.

Fix:Set Max-Age deliberately, taking browser caps into account.

Evolution

Original paper · 2014 · W3C Recommendation

Cross-Origin Resource Sharing (W3C Recommendation)

2014

W3C Recommendation "Cross-Origin Resource Sharing"

Inflection point

W3C publishes CORS as an official Recommendation (16 January 2014), standardizing the cross-origin access-control headers and the preflight mechanism.

2014

Folded into the WHATWG Fetch Standard

The CORS protocol is folded into the WHATWG Fetch Standard living specification, which now supersedes the W3C document — w3.org/TR/cors redirects to fetch.spec.whatwg.org.