← Back to glossary

PHP Sessions

PHP PHP 4.0+ Beginner

debt(d7/e3/b5/t7)

d7 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'only careful code review or runtime testing' (d7). No detection_hints provided; missing session_regenerate_id after login or missing httponly/secure cookie flags are not caught by syntax or default linters — they require security review or tools like PHPCS security rules. Silent in production until exploited.

e3 Effort Remediation debt — work required to fix once spotted

Closest to 'simple parameterised fix' (e3). Per quick_fix, the remediation is setting cookie params in php.ini or session_set_cookie_params() and adding session_regenerate_id(true)/session_destroy() calls — a small parameterised pattern, but touches login/logout flows so slightly more than a one-liner.

b5 Burden Structural debt — long-term weight of choosing wrong

Closest to 'persistent productivity tax' (b5). applies_to spans web and cli contexts; sessions are the default state mechanism touching authentication across the app. File-based sessions also force infrastructure decisions (load balancer affinity vs Redis), shaping deployment.

t7 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'serious trap' (t7). Misconception explicitly states devs believe HTTPS makes sessions secure — it doesn't prevent fixation/hijacking/persistence. The 'obvious' assumption (HTTPS = safe sessions) is wrong and contradicts intuition from other secure transport contexts.

About DEBT scoring → scored by claude-opus-4-7 · 2026-05-11 · reviewed by human

Also Known As

$_SESSION session_start PHPSESSID session handling PHP session

TL;DR

Server-side state storage identified by a cookie-based session ID — PHP's built-in mechanism for persisting data across HTTP requests, with security implications for how the session is started, stored, and terminated.

Explanation

PHP sessions work by: session_start() checks for a session cookie (PHPSESSID by default), creates a new session file (or entry in Redis/database) if none exists, and populates the $_SESSION superglobal from stored data. Session data is serialised to disk by default (session.save_path) or to a custom handler (Redis, Memcached, database). The session ID is sent to the browser as a cookie. Security requirements: session.cookie_httponly = true (prevents JavaScript access); session.cookie_secure = true (HTTPS only); session.cookie_samesite = 'Lax' (CSRF protection); session.use_strict_mode = true (rejects unrecognised session IDs); session_regenerate_id(true) after login (destroys old session, creates new — prevents session fixation); session_destroy() on logout (invalidates server-side data). PHP file-based sessions do not scale across multiple servers — use Redis or a database session handler for multi-server deployments.

Common Misconception

✗ Sessions are automatically secure when used with HTTPS. HTTPS encrypts the session ID in transit but does not prevent session fixation (where an attacker sets the session ID before login), session hijacking (where a valid session ID is stolen from an XSS vulnerability or network interception), or session persistence after logout (where session data remains on the server). All four security controls — httponly cookie, secure cookie, SameSite, and session_regenerate_id — are required together.

Why It Matters

Sessions are the default state mechanism for PHP web applications and the most common place authentication bugs are introduced. Missing session.cookie_httponly allows XSS to steal the session ID. Missing session_regenerate_id(true) after login allows session fixation. Using file-based sessions on a load-balanced server cluster causes users to be logged out when requests route to different servers. These are not theoretical issues — they are the actual vulnerabilities exploited in PHP application attacks.

Common Mistakes

Not calling session_start() at the beginning of every page that uses sessions — $_SESSION is empty without it.
Not regenerating the session ID after login — exposes the application to session fixation attacks.
Using file-based sessions in a multi-server environment — sessions are not shared across servers; use Redis.
Not calling session_destroy() on logout — invalidating the cookie without destroying the server-side data leaves the session exploitable if the cookie is obtained.

Code Examples

✗ Vulnerable

<?php
session_start();
// Login check — no regeneration
if (checkCredentials($_POST['user'], $_POST['pass'])) {
    $_SESSION['user'] = $_POST['user'];
    // No session_regenerate_id — session fixation possible
    // No secure/httponly cookie settings
}

✓ Fixed

<?php
// Secure session configuration
ini_set('session.cookie_httponly', '1');
ini_set('session.cookie_secure', '1');
ini_set('session.cookie_samesite', 'Lax');
ini_set('session.use_strict_mode', '1');

session_start();

if (checkCredentials($_POST['user'], $_POST['pass'])) {
    session_regenerate_id(true); // new ID, old destroyed
    $_SESSION['user_id']    = getUserId($_POST['user']);
    $_SESSION['logged_in']  = true;
    $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
    header('Location: /dashboard');
    exit;
}

References

https://www.php.net/manual/en/book.session.php