Access-Control-Expose-Headers header
Baseline
Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
The HTTP 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 Access-Control-Expose-Headers header.
| Header type | Response header |
|---|---|
| Forbidden request header | No |
Syntax
Access-Control-Expose-Headers: [<header-name>[, <header-name>]*]
Access-Control-Expose-Headers: *
Directives
<header-name>-
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.
*(wildcard)-
Any header. 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*.
Examples
The CORS-safelisted response headers are: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma. To expose a non-CORS-safelisted response header, you can specify:
Access-Control-Expose-Headers: Content-Encoding
To additionally expose a custom header, like Kuma-Revision, you can specify multiple headers separated by a comma:
Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision
For requests without credentials, a server can also respond with a wildcard value:
Access-Control-Expose-Headers: *
A server can also respond with the * value for requests with credentials, but in this case it would refer to a header named *.
Specifications
| Specification |
|---|
| Fetch # http-access-control-expose-headers |
Browser compatibility
Loading…