Access-Control-Allow-Headers response header is used in response to a preflight request which includes the
Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request.
This header is required if the request has an
|Header type||Response header|
|Forbidden header name||no|
Access-Control-Allow-Headers: <header-name>[, <header-name>]* Access-Control-Allow-Headers: *
- The name of a supported request header. The header may list any number of headers, separated by commas.
- The value "
*" only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name "
*" without special semantics. Note that the
Authorizationheader can't be wildcarded and always needs to be listed explicitly.
A custom header
Here's an example of what an
Access-Control-Allow-Headers header might look like. It indicates that a custom header named
X-Custom-Header is supported by CORS requests to the server (in addition to the CORS-safelisted request headers).
This example shows
Access-Control-Allow-Headers when it specifies support for multiple headers.
Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
Bypassing additional restrictions
Although CORS-safelisted request headers are always allowed and don't usually need to be listed in
Access-Control-Allow-Headers, listing them anyway will circumvent the additional restrictions that apply.
Example preflight request
Let's look at an example of a preflight request involving
First, the request. The preflight request is an
OPTIONS request that includes some combination of the three preflight request headers:
OPTIONS /resource/foo Access-Control-Request-Method: GET Access-Control-Request-Headers: Content-Type, x-requested-with Origin: https://foo.bar.org
If the CORS request indicated by the preflight request is authorized, the server will respond to the preflight request with a message that indicates the allowed origin, methods and headers. Below we see that
Access-Control-Allow-Headers includes the headers that were requested.
HTTP/1.1 200 OK Content-Length: 0 Connection: keep-alive Access-Control-Allow-Origin: https://foo.bar.org Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE Access-Control-Allow-Headers: Content-Type, x-requested-with Access-Control-Max-Age: 86400
If the requested method isn't supported, the server will respond with an error.
The definition of 'Access-Control-Allow-Headers' in that specification.
|Living Standard||Initial definition.|
|Chrome Full support 4||Edge Full support 12||Firefox Full support 3.5||IE Full support 10||Opera Full support 12||Safari Full support 4||WebView Android Full support 2||Chrome Android Full support Yes||Firefox Android Full support 4||Opera Android Full support 12||Safari iOS Full support 3.2||Samsung Internet Android Full support Yes|
|Wildcard (||Chrome Full support 63||Edge Full support 79||Firefox Full support 69||IE No support No||Opera Full support 50||Safari No support No||WebView Android Full support 63||Chrome Android Full support 63||Firefox Android No support No||Opera Android Full support 46||Safari iOS No support No||Samsung Internet Android Full support 8.2|
- Full support
- Full support
- No support
- No support