Sessions in Laravel: a PHP & Laravel guide for developers

Why Sessions Matter in Modern Web Applications

HTTP is stateless—each request arrives with no memory of the previous one. Without sessions, users would need to re-authenticate on every page load, and your application would have no way to remember their shopping cart, preferences, or login state. Sessions in Laravel: a PHP & Laravel guide for developers shows you how to bridge this gap and maintain user state across multiple requests, a fundamental capability for any web application serving real users.

Laravel abstracts away much of PHP's native session complexity, providing a clean, driver-agnostic interface that works seamlessly in single-server and distributed architectures. Understanding how to configure, use, and secure sessions is essential for building reliable applications that handle millions of user interactions daily.

Session Drivers: File, Database, and Redis

Laravel supports multiple session drivers, each with distinct trade-offs. Your choice depends on scale, infrastructure, and performance requirements. Let's examine the three most common options.

File Driver

The file driver stores session data as individual files in your storage/framework/sessions directory. This is the default for local development and works well for single-server applications with moderate traffic.

// config/session.php
'driver' => env('SESSION_DRIVER', 'file'),

The file driver is straightforward to debug—you can inspect session files directly. However, file I/O becomes a bottleneck under high concurrency, and file locking can cause contention. For production systems serving thousands of concurrent users, file storage often introduces visible performance degradation.

Database Driver

The database driver persists session data to a relational database table, typically PostgreSQL or MySQL. This is ideal when you already have infrastructure around your database and need reliable, queryable session storage.

// config/session.php
'driver' => env('SESSION_DRIVER', 'database'),
'table' => 'sessions',

To use the database driver, create the sessions table with Laravel's migration:

php artisan session:table
php artisan migrate

This creates a table with columns for id, user_id, ip_address, user_agent, payload, and last_activity. The main advantages are auditability and the ability to join session data with your application schema. The trade-off is that every session read and write hits your database, adding latency compared to in-memory stores.

Redis Driver

Redis is an in-memory data store optimized for fast key-value access. The Redis driver is the best choice for high-traffic applications requiring sub-millisecond session lookups.

// config/session.php
'driver' => env('SESSION_DRIVER', 'redis'),
'connection' => 'default',

Redis automatically handles session expiration through key TTL (time-to-live), requiring no manual cleanup. Session retrieval is orders of magnitude faster than disk-based drivers. For e-commerce platforms, SaaS applications, and real-time systems, Redis is the production standard.

Scaling Sessions Across Multiple Servers

When running your application across multiple servers behind a load balancer, the file driver fails immediately—each server maintains its own isolated filesystem, so a session created on Server A is invisible to Server B.

Consider a checkout flow on an e-commerce platform. A user logs in on Server A, adds items to their cart (stored in session). The load balancer routes their next request to Server B. With file storage, Server B has no knowledge of the cart, and the user must start over.

Use Redis or database for multi-server deployments. Both store session state centrally, accessible from any application instance.

// .env for production
SESSION_DRIVER=redis
REDIS_HOST=redis-cluster.internal
REDIS_PORT=6379
REDIS_PASSWORD=secure_password

In distributed architectures, Redis is preferred because it eliminates database load from session operations. A well-provisioned Redis cluster handles millions of sessions with minimal overhead, freeing your database to focus on application queries.

Regenerating Session IDs on Login

Session fixation is a security vulnerability where an attacker tricks a user into using a known session ID, then waits for the user to authenticate. Once authenticated, the attacker can reuse that same session ID to impersonate the user.

Always regenerate the session ID during login. Laravel makes this trivial with the regenerate() method.

// In your LoginController or authentication middleware
public function login(Request $request)
{
    $user = User::where('email', $request->email)->first();
    
    if ($user && Hash::check($request->password, $user->password)) {
        Auth::login($user);
        
        // Regenerate session ID to prevent fixation attacks
        $request->session()->regenerate();
        
        return redirect('/dashboard');
    }
    
    return back()->withErrors(['email' => 'Invalid credentials']);
}

Calling regenerate() creates a new session ID and migrates all existing session data to it. The old session ID is invalidated, preventing attackers who guessed or intercepted it from hijacking authenticated sessions.

Similarly, regenerate on logout to ensure the user cannot resume with the same session ID if their device is compromised later.

public function logout(Request $request)
{
    Auth::logout();
    $request->session()->invalidate();
    $request->session()->regenerateToken();
    
    return redirect('/');
}

Setting Secure and HttpOnly Cookies

Laravel stores the session ID in a cookie sent to the client. By default, this cookie is named LARAVEL_SESSION and is accessible to both the server and client-side JavaScript via document.cookie.

If your application is vulnerable to cross-site scripting (XSS), an attacker's injected JavaScript can read the session cookie and send it to a malicious server, hijacking the session. Prevent this with the httpOnly flag.

// config/session.php
'http_only' => true,
'secure' => true,
'same_site' => 'lax',

The http_only flag tells the browser to forbid JavaScript access to the cookie. The cookie is only sent automatically with HTTP requests, preventing client-side theft.

The secure flag ensures the cookie is only sent over HTTPS, protecting it from man-in-the-middle attacks on unencrypted connections. Always enable this in production.

The same_site attribute (set to lax or strict) mitigates cross-site request forgery (CSRF). lax allows the cookie to be sent with top-level navigations (safe for login flows) but blocks it on cross-origin form submissions. strict blocks it entirely in cross-site contexts.

// config/session.php - production settings
'cookie' => env('SESSION_COOKIE', 'laravel_session'),
'lifetime' => 120, // minutes
'expire_on_close' => false,
'secure' => env('SESSION_SECURE_COOKIES', true),
'http_only' => true,
'same_site' => 'lax',
'domain' => env('SESSION_DOMAIN', null),
'path' => env('SESSION_PATH', '/'),

Common Mistakes

Storing too much data in sessions. Each session read/write serializes and deserializes the entire payload. If you store megabytes of data, you'll degrade performance across your application. Store only small, frequently-accessed values like user IDs and preferences. Use your database for larger datasets.

Forgetting to regenerate on privilege escalation. Regenerate the session ID not only on initial login but also when user roles or permissions change significantly (e.g., enabling two-factor authentication). This prevents attackers from maintaining access after privilege changes.

Mixing file and Redis drivers in development/production. Local development with the file driver can mask multi-server issues that surface only in production with Redis. Use the same session driver across all environments, or invest time in local Redis setup for realistic testing.

Ignoring session garbage collection. Session files and database rows accumulate over time. Laravel includes a garbage collector, but verify it's configured and running. Set SESSION_LIFETIME appropriately for your use case—typically 120 minutes for web applications, shorter for sensitive finance or healthcare applications.

Not securing the session cookie. Shipping to production with secure disabled, http_only false, or same_site unset leaves sessions vulnerable to XSS and CSRF. Enforce these settings as non-negotiable.

Key Takeaways

• Use the file driver for local development only; choose Redis or database for production systems.
• Redis provides superior performance for high-traffic applications; the database driver suits smaller deployments with existing database infrastructure.
• Always use Redis or database when running multiple application servers behind a load balancer.
• Call regenerate() on login and logout to prevent session fixation attacks.
• Enable secure, http_only, and same_site cookie settings in production to defend against XSS and CSRF.
• Store minimal, frequently-accessed data in sessions; push larger datasets to the database.
• Monitor session storage size and garbage collection to prevent performance degradation.