Access-Control-Expose-Headers: reading response headers

The header does not change what the browser receives, only what page code can see. The full response, headers included, arrives intact; the fetch layer then hides anything outside the safelist, so a header you can see clearly in the network panel reads as null from JavaScript. That gap between the tooling and the code is why this one takes so long to diagnose.

The default safelist is short and static: cache and content descriptors plus a couple of dates. Everything a modern API actually wants to expose falls outside it, including ETag for conditional requests, Location after a create, Link for pagination, Retry-After on a rate limited response, and any correlation id you want a client to log.

It belongs on the real response. A preflight carrying the header changes nothing, because the browser reads it when it makes the response available to the caller. That is the opposite arrangement from the allow methods and allow headers lists, which only matter on the preflight.

The wildcard is available without credentials and is the pragmatic choice for a genuinely public API. With credentials it stops matching, so a session backed API has to enumerate the headers it wants readable, and any header not on that list becomes invisible to the very client that needs it.