Access-Control-Expose-Headers response header indicates which headers can be exposed as part of the response by listing their names.
By default, only the 7 CORS-safelisted response headers are exposed:
If you want clients to be able to access other headers, you have to list them using the
Content-Length was not part of the original set safelisted response headers [ref].
|Header type||Response header|
|Forbidden header name||no|
Access-Control-Expose-Headers: <header-name>, <header-name>, ... Access-Control-Expose-Headers: *
- A list of exposed headers consisting of zero or more header names other than the CORS-safelisted request headers that the resource might use and can be exposed.
- The value "
*" only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name "
*" without special semantics.
Note that the
Authorizationheader can't be wildcarded and always needs to be listed explicitly.
To expose a non-CORS-safelisted request header, you can specify:
To additionally expose a custom header, like
X-Kuma-Revision, you can specify multiple headers separated by a comma:
Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision
In requests without credentials, you can also use a wildcard value:
However, this won't wildcard the
Authorization header, so if you need to expose that, you will need to list it explicitly:
Access-Control-Expose-Headers: *, Authorization
The definition of 'Access-Control-Expose-Headers' in that specification.
BCD tables only load in the browser
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.