Access-Control-Expose-Headers response header allows a server to indicate which response headers should be made available to scripts running in the browser, in response to a cross-origin request.
Only the CORS-safelisted response headers are exposed by default. For clients to be able to access other headers, the server must list them using the
|Header type||Response header|
|Forbidden header name||no|
Access-Control-Expose-Headers: <header-name>, <header-name>, ... Access-Control-Expose-Headers: *
- A list of zero or more comma-separated header names that clients are allowed to access from a response. These are in addition to the CORS-safelisted response headers.
- 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.
The CORS-safelisted response headers are:
Pragma. To expose a non-CORS-safelisted response 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-Encoding, X-Kuma-Revision
For requests without credentials, a server can also respond with 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