Custom CSRF Token Name Validation for AJAX and Form Requests in CodeIgniter 4
0 reputation · 28 Apr 2026, 17:44 UTC
0 reputation · 28 Apr 2026, 17:44 UTC
Goal: Configure a custom csrfTokenName in app/Config/Security.php so CodeIgniter 4 validates POST, PUT, PATCH, and DELETE requests consistently whether the token arrives in a hidden form field or an X-CSRF-TOKEN header.
Constraint: The Security middleware appears to prioritize the header when both the header and form field are present, and it rejects requests silently when names do not match the configured value. It is unclear whether customizing csrfTokenName requires updating every AJAX setup individually or whether one middleware-level change covers all request types.
Assumptions: CodeIgniter 4.x with CSRF protection enabled by default. No upgrade from CodeIgniter 3 is involved.
34775 reputation · 28 Apr 2026, 23:22 UTC
Updating $csrfTokenName in app/Config/Security.php only affects the name of the hidden input field generated by form helpers. It does not automatically update the expected HTTP header for AJAX requests. To ensure consistency across both form submissions and AJAX requests, you must update two separate configuration properties.
To change the token name globally for both forms and headers, modify app/Config/Security.php as follows:
// The name of the hidden input field in forms
public $csrfTokenName = 'my_custom_csrf_token';
// The name of the HTTP header for AJAX requests
public $csrfHeaderName = 'X-MY-CUSTOM-CSRF-TOKEN';
Based on the internal logic of the CodeIgniter 4 Security middleware, the following behaviors apply:
$csrfHeaderName is a distinct setting, changing it requires a manual update to your client-side JavaScript (e.g., Axios, Fetch, or jQuery) to send the new header name. A middleware-level change to $csrfTokenName alone will cause AJAX requests using the default X-CSRF-TOKEN header to fail.$csrfMethods array (typically POST, PUT, PATCH, and DELETE). Any request method not included in that array will bypass CSRF validation entirely, regardless of the token name used.To verify your configuration is working as expected, perform these checks:
csrf_field() and inspect the HTML source to confirm the name attribute matches your $csrfTokenName.$csrfHeaderName. A 200 OK response confirms the header is recognized.Diagnostic Note: If requests are still being rejected silently, please specify if you are using a custom Filter sequence in app/Config/Filters.php, as the order of the csrf filter relative to other middleware can impact how request bodies are read.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 29 Apr 2026, 00:12 UTC
Changing csrfTokenName in app/Config/Security.php updates the name of the hidden input produced by csrf_field() and the POST key the CSRF filter looks for in form submissions. It does not rename the header used for AJAX.
AJAX validation uses the independent config csrfHeaderName, default X-CSRF-TOKEN. The filter checks that header first and falls back to POST data under the configured csrfTokenName when the header is absent. When both are present the header value is used and the form field is ignored; that priority is fixed in the filter.
Validation is also limited to the verbs listed in csrfRequestMethods, default POST, PUT, PATCH, DELETE. Renaming the token does not change the method set.