Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Laravel Sanctum 419 usually means the browser’s CSRF token and session state did not reach Laravel as expected, or the session expired. For a first-party single-page app (SPA), follow the request from CSRF initialization through cookies, middleware, and CORS before changing configuration. Sanctum’s SPA flow is cookie-based and intentionally uses CSRF protection; disabling that protection is not the default fix.
First, confirm which Sanctum authentication flow you are using
Sanctum has two distinct authentication paths. A first-party SPA uses Laravel’s session cookie and CSRF protection. An API client, such as a mobile app or a third-party integration, can authenticate with a personal access token sent as a bearer token. Laravel’s Sanctum documentation recommends the cookie-based SPA feature for first-party SPAs; an API token is not a replacement for that browser flow.
| Path | Credential mechanism | Browser credentials and CORS | Stateful origin |
|---|---|---|---|
| First-party SPA | Session cookie plus CSRF token | Relevant when the browser calls a separate origin; configure credentialed requests as needed | SPA origin must be included in Sanctum’s stateful domain configuration |
| API client | Personal access token sent as a bearer token | Not the cookie-based SPA flow | Not the first-party SPA stateful-origin setup |
The five checks below are for an SPA using session-cookie authentication.
1. Initialize the CSRF cookie before the protected request
Before login or another state-changing request, have the SPA request /sanctum/csrf-cookie. Laravel responds by setting an XSRF-TOKEN cookie. The subsequent request must send the URL-decoded cookie value in the X-XSRF-TOKEN header. Axios and some other clients can handle this automatically when configured to do so.
#1 Best Overall
- Open the browser’s developer tools and inspect the Network panel.
- Confirm that a request to
/sanctum/csrf-cookiecompleted before the failing POST. - Inspect the browser’s cookies for the API host and confirm that
XSRF-TOKENwas set. - Inspect the failing request’s headers and confirm it includes
X-XSRF-TOKEN.
If the initialization request never ran, fix the SPA’s request sequence first. If it ran but no cookie was stored, investigate host, scheme, cookie scope, and browser credential settings.
2. Check that the session cookie and matching token reach Laravel
Laravel’s CSRF middleware compares the token supplied with the request against the token associated with the session. A token header alone is not enough if the matching session cookie is missing or stale. Inspect the failing request—not only the earlier CSRF-cookie response—and verify that it carries both the expected session cookie and the XSRF header.
- Compare the frontend and API hostnames and schemes. A cookie scoped to one host or scheme may not be sent to the other.
- Check whether the browser blocked the cookie or whether its domain and path prevent it from matching the request.
- Compare the failing request’s token with the current XSRF cookie after URL decoding; a stale token can disagree with the session.
- Do not substitute a Sanctum personal access token for the SPA’s cookie-and-CSRF exchange.
Laravel’s CSRF protection documentation describes the CSRF-token mechanism. The VerifyCsrfToken API documentation identifies the middleware involved.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall3. Verify the stateful domain and middleware for your Laravel version
Sanctum must recognize the SPA as a first-party, stateful origin, and Laravel must apply the stateful API middleware. The SPA origin must match the configured domain; include the port for local development when needed. Laravel’s current Sanctum documentation also requires the SPA and API to share a top-level domain, although they may use different subdomains.
Rank #3
Laravel 11 and later
Laravel documents enabling Sanctum’s stateful API handling by calling statefulApi() in bootstrap/app.php. Check the application’s bootstrapping configuration and make sure the relevant API requests pass through the stateful middleware.
Earlier Laravel application generations
Older application structures register middleware differently. Use the setup instructions for the Laravel version actually running in the application rather than copying the Laravel 11-and-later configuration into an older project.
For either generation, compare the exact SPA origin—including any local-development port—with Sanctum’s configured stateful domains, then inspect the middleware stack for the failing URL. The version-specific setup is documented in Laravel Sanctum.
4. Check CORS credentials and cookie scope across subdomains
When the SPA and API use separate subdomains, the browser must be allowed to send credentials, and the session cookie must be scoped so both hosts can use it. Laravel documents enabling CORS credential support and configuring the frontend client to send credentials and XSRF data. Its Axios example sets withCredentials and withXSRFToken to true.
- Confirm that the CORS configuration permits the SPA origin and credentials; wildcard origins are not a substitute for a specific credentialed origin.
- Configure the browser client to send credentials and the XSRF token on the relevant requests.
- Check that the session cookie domain covers both the SPA and API subdomains. Laravel’s example uses a leading-dot root domain.
- Use the application’s real production domain and HTTPS arrangement; do not copy example domain placeholders literally.
If the request is same-origin, cross-origin CORS settings may not be the cause, but the request still needs the correct session and CSRF state.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.5. Decide whether the session expired
If the 419 appears after a period of inactivity, the session may have expired. Laravel’s Sanctum documentation states: “Of course, if your user’s session expires due to lack of activity, subsequent requests to the Laravel application may receive a 401 or 419 HTTP error response.” In that case, send the user back through the SPA login flow.
If the error happens on every fresh attempt, investigate the earlier checks first: missing CSRF initialization, absent or mismatched cookies and headers, incorrect stateful-domain or middleware setup, and credential or cookie-scope problems. That ordering follows the documented request flow; it does not mean every 419 has the same cause.
Recommended Free Tools
Check the route and middleware applied to the failing URL
Do not move a route between files as a blind fix. Laravel 12 documents that routes in web.php receive session state, CSRF protection, and cookie encryption through the web middleware group, while routes in api.php are stateless by default. A Sanctum SPA request needs the stateful configuration and middleware described above. Inspect the actual route and middleware stack for the failing URL before changing its location. See Laravel’s directory structure documentation for the route-file distinction.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
