Request Header Not Allowed by CORS: Fix the Header List
By Ankit Jain · Updated
Compare requested non-safelisted header names with Access-Control-Allow-Headers and explicitly allow Authorization.
Browser message
Typical wording varies by browser:
Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response.
What it means
The browser asked permission to send a request header that the API did not permit. Access-Control-Allow-Headers describes request header names, not response headers.
Evidence to inspect
Inspect Access-Control-Request-Headers on OPTIONS. Compare its names, case-insensitively, with Access-Control-Allow-Headers. A JSON POST usually requests content-type permission; a bearer token requests authorization permission.
Smallest safe fix
Permit only the headers the endpoint needs. Add their names to the OPTIONS response from the API or gateway. The actual token value does not belong in the permission response.
Example permission for an approved request (not a complete API policy):
Access-Control-Allow-Headers: Content-Type, Authorization, X-Request-IDAuthorization must be explicitly listed even when wildcard header permission could otherwise work. To read a custom response header, use Access-Control-Expose-Headers instead.
Verify the fix
Retry the same method and header set from the frontend. Verify that the actual request follows OPTIONS. If you need X-Request-ID from the response, test response.headers.get separately.
Use the CORS Tester to inspect public API headers or analyze a captured response. Confirm the result from the actual frontend afterward.
Continue learning
Request permission versus response exposure · Framework configuration · All errors