Vous lisez la version anglaise de ce contenu car il n’existe pas encore de traduction dans cette langue. Aidez-nous à traduire cet article !
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.
The CORS-safelisted request headers,
Content-Type are always allowed and don't need to be listed by this header necessarily. However, note that additional restrictions apply with these headers which you circumvent by listing these headers in an
Access-Control-Allow-Headers header as well.
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.
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 which includes some combination of the three preflight request headers:
Origin, such as:
OPTIONS /resource/foo Access-Control-Request-Method: DELETE Access-Control-Request-Headers: origin, x-requested-with Origin: https://foo.bar.org
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.
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 No support No||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