Request header field X-CSRF-TOKEN is not allowed by Access-Control-Allow-Headers in preflight response
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Fixing CORS Preflight Errors: Allowing Custom Headers like X-CSRF-TOKEN in Laravel
As developers building modern Single Page Applications (SPAs) that interact with backend APIs, Cross-Origin Resource Sharing (CORS) is a constant hurdle. While setting up basic CORS permissions seems straightforward, complex setups involving authentication tokens often run into specific issues during the preflight request phase.
Recently, I encountered a common frustration while developing a Laravel application: attempting to make an API request using Axios resulted in a confusing error: `Request header field X-CSRF-TOKEN is not allowed by Access-Control-Allow-Headers in preflight response.` This error halts the browser's ability to execute the request before it even hits your controller, making debugging seemingly impossible.
This post will dive deep into why this error occurs in a Laravel environment and provide a concrete, developer-focused solution for correctly configuring CORS middleware to permit necessary custom headers like `X-CSRF-TOKEN`.
## Understanding the CORS Preflight Mechanism
To understand the fix, we must first understand how CORS works, particularly the preflight request. When a browser attempts a "complex" request (one that uses non-simple HTTP methods or custom headers), it first sends an automatic `OPTIONS` request to the server. This is the **preflight** check.
The purpose of the preflight is for the client (browser) to ask the server: "Is it safe for me to send a real request with these specific headers and methods?"
For the server to respond positively, it must include the appropriate CORS headers in its response, specifically the `Access-Control-Allow-Headers` field. If you are sending a header like `X-CSRF-TOKEN`, the server *must* explicitly list this header in its response headers so the browser knows the request is permitted.
## The Diagnosis: Why Laravel Fails Here
In our scenario, the setup looked correct for standard CORS:
**Your Current Setup:**
You correctly implemented a custom middleware (`Cors.php`) to handle CORS:
```php
// Cors.php snippet
return $next($request)
->header('Access-Control-Allow-Origin','*')
->header('Access-Control-Allow-Methods','GET,POST,PUT,PATCH,DELETE,OPTIONS')
->header('Access-Control-Allow-Headers','Content-Type,Authorization'); // <--- The issue is here
```
The problem lies in the `Access-Control-Allow-Headers` list. While you allowed standard headers like `Content-Type` and `Authorization`, you omitted the custom header (`X-CSRF-TOKEN`) that your frontend application needs to send for authentication purposes. Because this header was not explicitly listed, the browser rejected the preflight response, leading to the error you observed.
## The Solution: Explicitly Allowing All Necessary Headers
The fix is straightforward: you need to modify your CORS middleware to include `X-CSRF-TOKEN` in the list of allowed headers. This ensures that when the server responds to the preflight `OPTIONS` request, it explicitly permits the subsequent requests containing this token.
Here is how you should update your `Cors.php` middleware:
```php
// Cors.php (Corrected Implementation)
public function handle($request, Closure $next)
{
$allowedHeaders = [
'Content-Type',
'Authorization',
'X-CSRF-TOKEN' // <-- ADDED THE REQUIRED HEADER HERE
];
return $next($request)
->header('Access-Control-Allow-Origin','*')
->header('Access-Control-Allow-Methods','GET,POST,PUT,PATCH,DELETE,OPTIONS')
->header('Access-Control-Allow-Headers', implode(', ', $allowedHeaders));
}
```
By explicitly listing `X-CSRF-TOKEN`, you satisfy the browser's security requirements during the preflight check. This pattern is crucial for building secure and flexible APIs in any framework, including Laravel. For more advanced insights into securing your API endpoints in Laravel, I highly recommend exploring the official documentation on [laravelcompany.com](https://laravelcompany.com).
## Conclusion
CORS errors involving custom headers like `X-CSRF-TOKEN` are rarely about a bug in your controller logic; they are almost always configuration issues within your CORS middleware. By carefully examining what headers your frontend application attempts to use and ensuring those exact headers are listed in the server's `Access-Control-Allow-Headers` response, you can resolve these frustrating preflight errors and ensure smooth, secure communication between your client and API.