Access-Control-Allow-Origin: who may read this response
Access-Control-Allow-Origin names the single origin permitted to read this response, or a wildcard for public resources. Without it, the browser blocks the page from seeing the body.
At a glance
- Direction
- Response only, on both the preflight and the actual response.
- Defined in
- The Fetch standard (WHATWG)
- When absent
- The browser fetched the response but refuses to let page code read it, and reports a CORS error.
- Accepted values
- One origin, the wildcard *, or the literal null. A list is not valid.
- With credentials
- The wildcard is rejected. You must echo the exact origin.
- Required companion
- Vary: Origin, whenever the value is computed from the request
- Does not affect
- Whether the request reached the server. It already did.
In detail
The most misunderstood part of CORS is that it does not stop the request. By the time the browser evaluates this header the server has already received the request and acted on it; what the header controls is whether page code is allowed to read the response. A state changing request that arrives without a preflight has still changed state, whatever the browser then reports.
The value is one origin or a wildcard, never a list. To support several origins, compare the incoming Origin header against your own allowlist and echo back exactly the one that matched. Echoing whatever arrives without checking turns the mechanism off completely, because every attacker page is happy to be echoed.
Credentialed requests, meaning those carrying cookies or an Authorization header, refuse the wildcard entirely. The response has to name the exact origin and also carry Access-Control-Allow-Credentials: true. That pairing is deliberate: it forces a server sharing per user data to state precisely who it is sharing with.
Because the value depends on the request, the response must carry Vary: Origin. Without it a shared cache stores the header generated for one origin and serves it to a page on another, producing a CORS failure that appears only for some users, only some of the time, and never on the machine of the person debugging it.
Examples
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=300Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: OriginThings that catch people out
- A comma separated list of origins is invalid. Browsers reject the whole header rather than matching one entry in it.
- Reflecting the Origin header without checking it against an allowlist is equivalent to a wildcard, but also works for credentialed requests, which makes it worse.
- Adding the header only to the successful path means your error responses have none, so client code sees a CORS failure instead of your 500 and reports the wrong bug.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Access-Control-Allow-Credentials: cookies across origins
What credentials mode means, the three wildcards it disables, what the client must also do, and why this header needs an exact origin in the response.
Origin: where a request was initiated from
When browsers send Origin, why it is only scheme, host and port, when the value is null, and how to use it for cross-site request forgery defence.
Vary: which request headers change the response
How Vary extends a cache key, why Vary: User-Agent destroys hit rates, what Vary: * means, and the CORS case where forgetting Vary: Origin causes real bugs.
Access-Control-Allow-Methods: permitted methods on preflight
Where the allow methods header belongs, why it appears only on the preflight response, which methods never need it, and how it interacts with caching.
Access-Control-Allow-Headers: permitted request headers
Which request headers trigger a preflight, how to answer with the right allow list, and the one header a wildcard never covers.
Access-Control-Expose-Headers: reading response headers
Which response headers page code can read cross-origin by default, how to expose more, and why a pagination or request id header appears empty without it.
Tools for this
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL