Sessions and Cookies

Analogy categoryAnalogies

HTTP is stateless — by default, a server has no memory of a client between one request and the next. Cookies and sessions are the two complementary mechanisms PHP provides to bridge that gap. A cookie is a small piece of data the server asks the browser to store and automatically resend on every subsequent request to the same site; PHP exposes outgoing cookies via setcookie() and reads incoming ones via the $_COOKIE superglobal. A session goes further: PHP stores arbitrary data server-side (in files by default, though Redis or a database are common in production) and issues the browser only a single cookie containing an opaque session ID, so sensitive data like 'is this user logged in and as whom' never has to leave the server at all.

🏏

Cricket analogy: A one-day match has no memory of yesterday's game unless someone hands the umpire a written note of the score to carry forward; cookies are that note the browser carries in its pocket, while a session is the team manager keeping the real details locked in the pavilion.

Working with cookies directly

setcookie() must be called before any HTML output is sent, because cookies are transmitted as an HTTP header (Set-Cookie) and PHP cannot add headers once the response body has started streaming. Beyond the name and value, the options array controls expires (when the browser should discard it), path and domain (which URLs it's sent on), secure (only send over HTTPS), httponly (inaccessible to JavaScript, blocking a common XSS exfiltration vector), and samesite (Lax, Strict, or None — restricting whether the cookie is sent on cross-site requests, a key defense against CSRF).

🏏

Cricket analogy: A ground announcer must confirm the day's playing conditions — pitch report, weather call — before the toss coin is even flipped, because once play starts those conditions can't be re-announced; setcookie() must fire before any HTML output the same way.

php

<?php
declare(strict_types=1);

// Cookie: remember a UI preference, not sensitive data.
setcookie('theme', 'dark', [
    'expires'  => time() + 60 * 60 * 24 * 30,
    'path'     => '/',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

// Session: server-side state for authentication.
session_start();

function attemptLogin(string $username, string $passwordHash): bool
{
    $stored = lookupUser($username); // hypothetical lookup
    if ($stored !== null && password_verify($passwordHash, $stored['password'])) {
        session_regenerate_id(true); // prevent session fixation
        $_SESSION['user_id'] = $stored['id'];
        $_SESSION['logged_in_at'] = time();
        return true;
    }
    return false;
}

How PHP sessions work under the hood

Calling session_start() either creates a new session or resumes an existing one: PHP checks the incoming request for a cookie named PHPSESSID (configurable), and if present, loads the matching session data from storage (by default, a file in the directory configured by session.save_path) into the $_SESSION superglobal array. If absent, PHP generates a new random session ID, sends it back as a Set-Cookie header, and starts $_SESSION empty. Any writes to $_SESSION during the request are automatically serialized back to storage when the script ends (or immediately if you call session_write_close()).

🏏

Cricket analogy: A returning spectator shows their gate wristband from yesterday, and stadium staff look up their seating record from that wristband code; if they show up without one, staff issue a brand-new wristband and start a fresh empty record — just like session_start() checking for PHPSESSID.

A cookie is like a claim ticket at a coat check: the ticket itself (the session ID) is small and meaningless on its own, but it lets the attendant (the server) retrieve your actual coat (the session data) from the back room. Anyone who steals the ticket can claim your coat — which is exactly why protecting the session cookie (httponly, secure, regenerating on login) matters so much.

Failing to call session_regenerate_id() after a successful login leaves an application vulnerable to session fixation: an attacker who tricks a victim into using an attacker-known session ID before login can hijack that same session ID's now-authenticated state after the victim logs in.

Cookies are small client-stored values sent automatically by the browser on every matching request; sessions store data server-side, keyed by an opaque session ID cookie.
setcookie() must be called before any output is sent, since cookies are transmitted via an HTTP response header.
The secure, httponly, and samesite cookie flags are essential defenses against interception, XSS exfiltration, and CSRF respectively.
session_start() resumes an existing session via the PHPSESSID cookie or creates a new one, populating $_SESSION.
session_regenerate_id(true) should be called immediately after privilege changes like login, to prevent session fixation attacks.
By default PHP session data is stored in files on the server (session.save_path), but production systems commonly swap in Redis or database-backed storage.