The Access-Control-Allow-Headers response header is returned by servers during a CORS preflight (OPTIONS) request to indicate which HTTP headers the client is permitted to send in the actual request.

When is this header required?

When a browser makes a cross-origin request containing headers that are not CORS-safelisted (e.g., Authorization, X-Api-Key, Content-Type: application/json), it first sends an OPTIONS request carrying:

Access-Control-Request-Headers: authorization, content-type, x-custom-trace

The server must reply with Access-Control-Allow-Headers authorizing those headers:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.test
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type, X-Custom-Trace
Access-Control-Max-Age: 86400

If any requested header is omitted from Access-Control-Allow-Headers, the browser blocks the subsequent actual request.

How to test with curl

Simulate a preflight check with curl:

curl -i -X OPTIONS https://api.example.test/v1/users \
  -H "Origin: https://app.example.test" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: authorization, content-type"

Key takeaway

Access-Control-Allow-Headers grants permission for non-safelisted request headers. Include all client-supplied custom headers (such as Authorization and X-*) in your preflight handler response.