Laravel 13 Security Upgrade Checklist: CSRF, Cache and Session Changes

Laravel 13, released on March 17, 2026, is a small upgrade by design: the release notes describe minimal breaking changes. But a handful of the changes in the official upgrade guide have real security consequences, and two of them can log every user out on deploy if you are not ready for them.

This is the security checklist for that upgrade. For the general comparison, new features and support dates, see Laravel 12 vs 13.

Before you start: PHP 8.3

Laravel 13 requires PHP 8.3 or later. Laravel 12 supports 8.2. Move servers, CI runners and Docker base images first, as a separate deploy. Running a PHP version that still receives security support is part of the point of upgrading.

1. CSRF becomes request forgery protection

Upgrade guide impact: high.

The VerifyCsrfToken middleware is renamed PreventRequestForgery. Beyond the name, it adds origin-aware checks: it uses the browser's Sec-Fetch-Site request header to tell whether a request came from your own site or from another origin, on top of the CSRF token check.

That is a genuine improvement. Token checks stop forged requests that lack a valid token, and origin checks add a second, independent signal that modern browsers send automatically.

VerifyCsrfToken and ValidateCsrfToken remain as deprecated aliases, so code that references them keeps working. Laravel 13 also adds a preventRequestForgery(...) method for configuring the middleware in bootstrap/app.php.

What to check:

• Search your code for VerifyCsrfToken and ValidateCsrfToken, including subclasses, tests that disable the middleware with withoutMiddleware(...), and package service providers. Update references to PreventRequestForgery.
• Review your exemption list. Every exempted path is a route with no forgery protection at all. Webhook exemptions are legitimate, but they should be narrow (webhooks/stripe, not webhooks/* or api/*).
• Test legitimate cross-origin flows: forms posted from a marketing site on another domain, embedded widgets, or payment provider redirects that post back to you. Origin checks are designed to stop cross-site posts, so anything that relied on them will need an explicit, deliberate exemption.

2. Cache unserialization is hardened

Upgrade guide impact: medium.

The cache configuration's serializable_classes option now defaults to false. In the upgrade guide's words, this hardens cache unserialization to help prevent PHP deserialization gadget chain attacks if your application's APP_KEY is leaked.

The reason this matters: deserialization of attacker-influenced data is how a leaked key turns into remote code execution, and researchers have found more than 260,000 Laravel keys in public repositories. We cover that attack in detail in Your Laravel APP_KEY Leaked.

What to check:

• Find where you cache objects rather than scalars or arrays, for example Cache::remember('user:'.$id, ..., fn () => User::find($id)).
• Either cache arrays and IDs instead, or list the specific classes you need in serializable_classes.
• Do not set it to true to make the errors go away. That restores exactly the behaviour the change removes.

3. Sessions serialize as JSON in new applications

Upgrade guide impact: low.

The Laravel 13 application skeleton sets the session serialization option to json. JSON cannot carry PHP objects, which removes object unserialization from session handling entirely.

Upgraded applications keep whatever they have configured. Switching from php to json logs out every active session, and any code that stores objects in the session will stop working.

What to check:

• Search for session()->put(...) and Session::put(...) calls that store objects, and store arrays or IDs instead.
• Make the switch to json as its own planned deploy, not as part of the framework upgrade, so a mass logout has one obvious cause.
• If you use the cookie session driver (SESSION_DRIVER=cookie), this change matters most: your whole session lives in a cookie the client sends back. Consider moving to the database or Redis driver at the same time.

4. Default cookie and cache prefix names change

Upgrade guide impact: low.

The fallback values for the session cookie name and the cache and Redis prefixes changed from an underscore separator to a hyphen (_session becomes -session). They only apply if you never set the values yourself.

If you rely on the fallbacks, the upgrade renames your session cookie, which logs everyone out, and changes your cache prefix, which leaves you with a cold cache.

What to check:

• Look up the session cookie name your production app sets today (browser developer tools, Application tab, Cookies).
• Set SESSION_COOKIE to that exact value, and set CACHE_PREFIX and REDIS_PREFIX to the prefixes you use today.
• Deploy those environment variables on Laravel 12 first, so the framework upgrade changes nothing.

What did not change

It is worth being explicit, because an earlier version of this article got this wrong. Laravel 13 does not:

• change the default encryption cipher. Existing encrypted data needs no migration.
• change the bcrypt or Argon2 hashing defaults. Existing password hashes keep working.
• change the default users, password_reset_tokens or sessions migrations.

If you are reading advice that tells you to re-encrypt your data or rehash passwords because of Laravel 13, check it against the upgrade guide.

Post-upgrade security checklist

Run through this after the upgrade is deployed:

• APP_DEBUG is false and APP_ENV is production in the deployed environment, not just in your pipeline.
• Your session cookie still has Secure, HttpOnly and an appropriate SameSite value, and its name did not change unexpectedly.
• Request forgery exemptions are as narrow as they were, or narrower.
• Telescope, Horizon and any debug tooling are still gated after the upgrade. Package upgrades that come with a major version are a common point where a gate gets lost.
• composer audit is clean, and runs in CI on every build.
• Your production servers run PHP 8.3 or later.

The open source stackshield/scanner checks most of the configuration items above from inside your app with one artisan command, and supports Laravel 13. To check what the deployed application actually exposes to the internet, run a free StackShield scan.

Support timeline

Laravel 12 stopped receiving bug fixes on August 13, 2026 and receives security fixes until February 24, 2027. Laravel 13 receives security fixes until March 17, 2028. Dates are from the Laravel support policy.