When adding token-based authentication to a web application, developers frequently encounter this browser console error: Request header field Authorization is not allowed by Access-Control-Allow-Headers in preflight response.

Why Authorization triggers a preflight

Under the CORS specification, only a small set of standard headers are considered “CORS-safelisted” (Accept, Accept-Language, Content-Language, Content-Type, and Range).

The Authorization header carries sensitive credentials (such as Authorization: Bearer <token> or Basic credentials). Because it is not in the safelisted set, any cross-origin browser request including an Authorization header automatically triggers an OPTIONS preflight request, even if the method is a simple GET.

What Access-Control-Request-Headers communicates

When the browser identifies that the intended request contains an Authorization header, it sends an OPTIONS preflight containing:

Access-Control-Request-Headers: authorization

This request header informs the server: “The upcoming cross-origin request wants to use the Authorization header. Does your CORS policy allow this?”

What Access-Control-Allow-Headers communicates

The server must reply to the OPTIONS preflight with the Access-Control-Allow-Headers response header, listing all non-safelisted headers the client is permitted to send:

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

If the server response omits Authorization (or omits Access-Control-Allow-Headers entirely), the browser’s preflight check fails immediately.

Why Authorization must be listed explicitly

While the CORS specification permits Access-Control-Allow-Headers: * for non-credentialed requests, credentialed requests or specific browser implementations often require explicit header enumeration.

Listing Authorization explicitly in the server’s CORS configuration guarantees compatibility across all browsers and credential modes.

Browser CORS restriction versus API authentication

It is important to separate CORS header validation from API token validation:

  • CORS header validation: The browser checks if the server allows the client to send the Authorization header. This check happens during the OPTIONS preflight, before the token is sent.
  • API token validation: The server inspects the bearer token or credentials inside the actual GET or POST request to verify user identity.

If an authentication filter intercepts the preliminary OPTIONS request and demands a token, it creates a circular failure: the browser refuses to send the token until the preflight succeeds, but the preflight fails because the server demands a token.

Common causes

Access-Control-Allow-Headers Omits Authorization

The API server preflight response lists other headers (such as Content-Type) but omits Authorization, causing the browser to reject the cross-origin request.

Authentication Middleware Intercepts Preflight Before CORS

Backend authentication middleware checks for credentials on the OPTIONS request itself and rejects it with 401 or 403 before the CORS response headers can be attached.

Wildcard Header Misinterpretation

The server attempts to use a wildcard for allowed headers on credentialed requests where explicit header enumeration is required by the browser.

Reverse Proxy Filters CORS Response Headers

An API gateway or reverse proxy strips or replaces the Access-Control-Allow-Headers response header sent by the origin service.

What to check before changing code

  1. Inspect the OPTIONS preflight request and response in DevTools: Look at the Network tab for the preflight request preceding your actual API call. Check Access-Control-Request-Headers in the request and Access-Control-Allow-Headers in the response.
  2. Verify middleware execution order: Confirm that your web framework’s CORS middleware executes before any authentication or authorization middleware in the pipeline.
  3. Check casing and spelling: While HTTP header names are case-insensitive, verify that authorization is listed in your server’s allowed headers configuration.

How to verify the fix

Test the server’s preflight handling directly using curl with the simulated preflight headers:

curl -i -X OPTIONS https://api.example.test/v1/user \
  -H "Origin: https://app.example.test" \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: authorization"

Verify that the response includes Access-Control-Allow-Headers containing authorization, and that the status code is 200 or 204.

Key takeaway

Sending an Authorization header across origins triggers an automatic OPTIONS preflight request. The API server must respond with Access-Control-Allow-Headers explicitly allowing Authorization. Ensure your server’s CORS middleware handles OPTIONS requests before any authentication filters run.