Overview

Access-Control-Allow-Origin (ACAO) is the core CORS header specifying which origin may read this response beyond the browser's Same-Origin Policy (SOP). If it's absent or doesn't match the request origin, the browser blocks access to the response body.

The value is a specific origin (e.g. https://app.example.com) or the wildcard * allowing all origins.

Details

* permits access from any origin but is only safe for public, non-credentialed resources. To allow origins selectively, the server inspects the request's Origin header and, if it is on an allowlist, reflects that value back. In that case it must also emit Vary: Origin so caches don't mix per-origin responses.

Requests carrying credentials (cookies, HTTP auth, client certs) cannot use *. The browser requires a specific single origin together with Access-Control-Allow-Credentials: true — so in credentials mode, ACAO: * is rejected.

ACAO is needed both on the actual response of simple requests and on the preflight (OPTIONS) response. In a preflight it is checked alongside Access-Control-Allow-Methods and Access-Control-Allow-Headers.

Syntax

Access-Control-Allow-Origin: <origin> | *

e.g. Access-Control-Allow-Origin: https://app.example.com

Notes

• Common misconception: CORS is not a defense that protects the server; it is a rule about whether the browser hands a response to scripts of another origin. curl and server-to-server calls are unaffected by CORS.
• Reflecting Origin back without validation is effectively allowing every origin, and combined with credentials it leads to serious data exposure. Always filter through an allowlist.
• There is no syntax for listing multiple origins with commas (ACAO is exactly one origin or *). Multi-origin support is implemented by the server choosing and reflecting one per request.

Related headers

Related status codes

Specification