Overview

Access-Control-Allow-Headers is the CORS preflight-response header that declares which custom or non-simple request headers a cross-origin actual request may send. Including a header not permitted here in the real request gets blocked by the browser.

The value lists allowed header names separated by commas, and for non-credentialed requests * is allowed.

Details

To send custom/non-simple headers like Authorization, Content-Type: application/json, or X-Requested-With on a cross-origin request, the browser first announces them in the preflight via Access-Control-Request-Headers. The server must answer with the permitted ones in Access-Control-Allow-Headers before the browser will send them on the real request.

* allows all headers but is invalid in credentials mode; notably the wildcard does not cover the Authorization header (per browser behavior), so if you need the auth header, list it explicitly to be safe.

This header governs headers the request may send, whereas exposing headers the script may read from the response is Access-Control-Expose-Headers. The directions are opposite — don't confuse them.

Syntax

Access-Control-Allow-Headers: <header>[, <header>]* | *

e.g. Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With

Notes

• The most common CORS error: the client sends Authorization or a custom header but the server didn't include it in Access-Control-Allow-Headers, so the preflight fails.
• Header names are case-insensitive, but list them to match exactly what the request intends to send. Don't forget headers a client library adds automatically (like X-Requested-With).
• This header also appears only on the preflight (OPTIONS) response; there's no need to put it on the actual response.

Related headers

Related status codes

Specification