Access-Control-Allow-Headers

The HTTP Access-Control-Allow-Headers response header specifies which HTTP headers are permitted in a cross-origin request. Servers return this header as part of a CORS preflight response.

Table of Contents

Usage
Directives
- Header name list
- * (wildcard)
Example
Troubleshooting
See also

Usage

When a browser issues a preflight OPTIONS request, the Access-Control-Request-Headers header lists the non-safelisted headers the client intends to send. The server replies with Access-Control-Allow-Headers to confirm which of those headers are accepted.

CORS-safelisted headers are always permitted and do not need to appear in this list. The safelisted set includes Accept, Accept-Language, Content-Language, Content-Type (with restrictions on media type and value length), and Range (with restrictions on the format). Listing a safelisted header explicitly removes the extra restrictions on the value.

Multiple header names appear as a comma-separated list.

Directives

Header name list

A comma-separated set of header names the server accepts in the actual request.

Access-Control-Allow-Headers: Content-Type, Authorization

* (wildcard)

The asterisk acts as a wildcard for requests without credentials, permitting any header name.

Access-Control-Allow-Headers: *

Note

For credentialed requests the wildcard * is treated as a literal string, not as a wildcard. Each allowed header must be listed explicitly when credentials are present. The Authorization header is never covered by the wildcard and must always be named explicitly.

Example

A preflight request asks whether Content-Type and a custom X-Request-ID header are allowed. The server confirms both.

Request

OPTIONS /api/data HTTP/1.1
Origin: https://app.example.re
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, X-Request-ID

Response

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.re
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, X-Request-ID
Access-Control-Max-Age: 86400

A server using the wildcard for non-credentialed requests responds with a single character.

Access-Control-Allow-Headers: *

Troubleshooting

Preflight failures related to request headers produce console errors and block the actual request.

Console shows "Request header field X is not allowed by Access-Control-Allow-Headers in preflight response." The server did not list the header name in the Access-Control-Allow-Headers value. Add the missing header to the preflight response. In nginx: add_header Access-Control-Allow-Headers "Content-Type, Authorization, X-Request-ID"; In Apache: Header set Access-Control-Allow-Headers "Content-Type, Authorization, X-Request-ID"
Preflight response missing the header entirely. The server handles the OPTIONS request but does not include Access-Control-Allow-Headers in the response. Many frameworks require explicit CORS configuration for preflight routes. Check that the OPTIONS handler or middleware sets this header alongside Access-Control-Allow-Methods and Access-Control-Allow-Origin.
Wildcard * not working with credentialed requests. When Access-Control-Allow-Credentials is true, the wildcard is treated as the literal string * and matches nothing. List each allowed header explicitly. The Authorization header is never covered by the wildcard even for non-credentialed requests and must always be named.
Header names appear case-sensitive in some servers. HTTP header names are case-insensitive per the protocol, but some server frameworks perform case-sensitive string matching when checking the allowed list. A request sending content-type may fail if the server only lists Content-Type. Match the casing the client sends or normalize both sides to lowercase in the CORS configuration.
Sending Content-Type: application/json triggers an unexpected preflight. The Content-Type header is safelisted only for values application/x-www-form-urlencoded, multipart/form-data, and text/plain. The value application/json falls outside the safelist and forces a preflight. Add Content-Type to the Access-Control-Allow-Headers list. To confirm the preflight triggers, open DevTools Network tab and filter by method to spot the OPTIONS request preceding the actual request.