The 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 Access-Control-Request-Headers header.
| Header type | Response header |
|---|---|
| Forbidden header name | no |
Syntax
Access-Control-Allow-Headers: <header-name>[, <header-name>]* Access-Control-Allow-Headers: *
Directives
<header-name>- The name of a supported request header. The header may list any number of headers, separated by commas.
*(wildcard)- 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 theAuthorizationheader can't be wildcarded and always needs to be listed explicitly.
Examples
A custom header
Here's an example of what an Access-Control-Allow-Headers header might look like. It indicates that in addition to the CORS-safelisted request headers, a custom header named X-Custom-Header is supported by CORS requests to the server.
Access-Control-Allow-Headers: X-Custom-Header
Multiple 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.
Access-Control-Allow-Headers: Accept
Example preflight request
Let's look at an example of a preflight request involving Access-Control-Allow-Headers.
Request
First, the request. The preflight request is an OPTIONS request which includes some combination of the three preflight request headers: Access-Control-Request-Method, Access-Control-Request-Headers, and Origin, such as:
OPTIONS /resource/foo Access-Control-Request-Method: DELETE Access-Control-Request-Headers: origin, x-requested-with Origin: https://foo.bar.org
Response
If the server allows CORS requests to use the DELETE method, it responds with an Access-Control-Allow-Methods response header, which lists DELETE along with the other methods it supports:
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-Max-Age: 86400
If the requested method isn't supported, the server will respond with an error.
Specifications
| Specification | Status | Comment |
|---|---|---|
| Fetch The definition of 'Access-Control-Allow-Headers' in that specification. |
Living Standard | Initial definition. |
Browser compatibility
| Desktop | Mobile | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Access-Control-Allow-Headers | 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 |
Legend
- Full support
- Full support
- No support
- No support
