This is a response header which provides help in indicating what all headers can actually be exposed as a part of the response by listing their names. By default, the 6 simple response headers that are exposed include; Cache-Control, Content-Language, Content-Type, Expires, Last-Modified and Pragma. If we want clients so as to be able to access various other headers, we have to list them using this header. All possible values for this header are given in a comma-delimited list consisting of all the response headers that we want to expose to client.
This header allows a server to white list all the headers that the browsers are allowed to access. That is, the syntax “Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header” automatically allows headers such as, “X-My-Custom-Header” and “X-Another-Custom-Header” so as to be exposed to browser.
CORS is said to be implemented in a way such that it doesn’t break the assumptions that are made in the world of pre-CORS, same-origin-only. In pre-CORS world, any given client can trigger a specific cross-origin request (that is, through a script tag), but it cannot read the response headers. Now, to make sure that CORS does not break the discussed assumption, this specification (which is CORS) requires server to provide explicit permissions for client in order to read those headers (through the use of the header under consideration). By this way, the unauthorized CORS requests tend to behave like they did in any pre-CORS world.
Enablement in Apache:
The below mentioned syntax is added in the configuration file.
Header always set Access-Control-Expose-Headers “Access-Control-Allow-Origin,Access-Control-Allow-Credentials”
Enablement in Nginx:
The syntax given below is added in the “nginx.conf” file.
add_header ‘Access-Control-Expose-Headers’ ‘Content-Length,Content-Range’;
add_header ‘Access-Control-Expose-Headers’ ‘Authorization’ always;