Reproduce the problem with a harmless form in a private browser window. Record the affected hostname, HTTPS behavior and whether it occurs after a long idle period or immediately after login.

1. Check that the form includes the CSRF token generated by Laravel and sends the intended request method. For JavaScript requests, verify the application uses the framework-supported token or session flow.

2. Inspect the browser request and cookies. Confirm the cookie domain, path, Secure setting and SameSite behavior fit the actual frontend and backend origins.

3. Verify the session backend is writable and available. For more than one application instance, check that sessions and encryption configuration are consistent across them.

4. Check reverse-proxy HTTPS handling and remove caching from personalized forms or authenticated responses. A cached page can contain a stale token from a different session.

5. After correcting configuration, refresh caches and persistent workers where relevant. Start a new browser session and repeat the same form workflow.

Test login, an authenticated form and a form after the intended idle interval. A working GET page alone does not validate session cookies on POST requests.

If the error follows a domain change, compare old cookies with the new canonical host. If it appears only on some requests, investigate load balancing and shared session storage.

• Keeping a Laravel application key safe during migration
• Refreshing Laravel configuration after environment changes
• Troubleshooting browser CORS errors for an API
• Checking Laravel health without exposing private data

• Laravel CSRF protection
• Laravel sessions