The Access-Control-Allow-Headers header specifies which HTTP headers can be used in the actual cross-origin request.
When a cross-origin request includes non-safelisted headers, the browser sends a preflight request to check if those headers are allowed. The server must respond with this header listing the permitted headers for the actual request to proceed.
Syntax & Values
Access-Control-Allow-Headers: <header> Access-Control-Allow-Headers: <header>, <header>, ... Access-Control-Allow-Headers: *
The Access-Control-Allow-Headers header accepts one or more header names (e.g., X-Custom-Header or Content-Type, Authorization) to specify which headers are allowed in the actual request. Additionally, the wildcard * can be used to allow all headers.
Examples
Allowing a single custom header
Permits the X-API-Key header to be used in the actual cross-origin request.
Access-Control-Allow-Headers: X-API-Key
Allowing multiple headers
Permits multiple headers such as Content-Type and Authorization to be used in the actual request. Headers are comma-separated.
Access-Control-Allow-Headers: Content-Type, Authorization
Allowing all headers
Permits any header to be used in the actual request. This is convenient but less secure than explicitly listing allowed headers.
Access-Control-Allow-Headers: *
Common Errors & Fixes
Missing token (e.g., 'xyz') in the CORS Access-Control-Allow-Headers header.
Ensure the server's response includes the required header token in the Access-Control-Allow-Headers value.
Frequently Asked Questions
Is the Access-Control-Allow-Headers (ACAH) header needed on the actual resource response?
No. Only the preflight response needs it.
Is the Access-Control-Allow-Headers header case-sensitive?
No, HTTP header names are generally case-insensitive. However, the values (the header names listed) might be case-sensitive depending on the server-side implementation, though the specification implies they should be treated case-insensitively.