CORS Cross Origin
Header Not Allowed
Reviewed for reference consistency: August 11, 2026
Request header field is not allowed by Access-Control-Allow-Headers in preflight response.
What Header Not Allowed Means
The Header Not Allowed error on the CORS Cross Origin indicates header not allowed — request header field is not allowed by access-control-allow-headers in preflight response.. This typically occurs due to the frontend application is attempting to send a custom header (e.g., 'x-custom-auth', 'x-requested-with') that the backend hasn't explicitly whitelisted..
Even if a backend server successfully allows the origin and permits the specific HTTP method (like POST or PUT), it must also explicitly authorize any non-standard HTTP headers the frontend wishes to send. This granular authorization is checked during the preflight (OPTIONS) phase. If the server's 'Access-Control-Allow-Headers' response does not explicitly list the exact custom header requested by the frontend, the browser aggressively blocks the request.
How to fix Header Not Allowed
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Update Allow-Headers directive
Configure the backend application or proxy to include the rejected header string in its Access-Control-Allow-Headers response.
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, X-Custom-Auth';Check frontend fetch logic
Inspect your frontend network code (fetch, Axios interceptors) to ensure you aren't accidentally attaching unnecessary custom headers that the backend doesn't expect.
Technical Background
The CORS specification divides HTTP headers into two categories: 'simple' headers and all others. Browsers allow a few specific, simple headers (like Accept, Accept-Language, and standard form Content-Types) to be sent cross-origin without requiring explicit preflight permission.
If your JavaScript code attempts to attach any other header (such as an API key, a JWT token, or a custom application state header), the browser mandates that the server explicitly approve that specific header.
During the preflight OPTIONS request, the browser sends an 'Access-Control-Request-Headers' header listing every custom header it wants to use. The server must reply with an 'Access-Control-Allow-Headers' header echoing back approval for those requested headers.
If the server's response does not include the exact header name you are trying to send, the browser determines the server isn't prepared to handle it, and the entire request is blocked before the actual data is transmitted.
Common Causes
- The frontend application is attempting to send a custom header (e.g., 'X-Custom-Auth', 'X-Requested-With') that the backend hasn't explicitly whitelisted.
- The frontend is sending data with 'Content-Type: application/json', but the backend CORS configuration only allows standard form content types.
- The preflight response's 'Access-Control-Allow-Headers' directive only allows a limited subset of headers, omitting one required by the frontend.
Typical Scenarios
- A developer adds an 'Authorization' header to authenticate an API request, but the backend doesn't explicitly list 'Authorization' in its allowed headers.
- Adding a custom distributed tracing header like 'X-Request-Id' or 'X-Correlation-Id' to track requests across microservices.
- Using a frontend library or framework that automatically injects a custom header under the hood (e.g., the 'X-Requested-With' header injected by jQuery AJAX).
What to Know
Look closely at the browser console error—it will usually specify exactly which header name was rejected. Then, update your backend's CORS configuration or reverse proxy settings to append that specific string to the Allow-Headers list. If you are using a wildcard (*), remember that it will fail if the request relies on cookies or credentials.
Frequently Asked Questions
Common questions about CORS Header Not Allowed error
Because 'Authorization' is not considered a 'simple' header by the CORS specification. The server must explicitly whitelist it by including it in the Access-Control-Allow-Headers response during the preflight phase, otherwise the browser considers it a security risk.
Yes, modern browsers support using '*' for the Allow-Headers directive, which permits any custom header. However, just like with the Allow-Origin wildcard, you cannot use the '*' wildcard for headers if the request is being made with credentials (cookies).
When you send form data, the Content-Type is typically 'application/x-www-form-urlencoded', which is a 'simple' header. When you send JSON, you change it to 'application/json', which requires a preflight check. Your backend must explicitly allow the 'Content-Type' header in its CORS configuration to support JSON payloads.
Related Error Codes
Related Errors From Other Categories
Similar error codes documented across different platforms and systems