Sessions and Cookies
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
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.
Practice what you learned
1. Why must setcookie() be called before any HTML output is sent?
2. What is the primary purpose of the httponly cookie flag?
3. What does session_start() do when a request contains no valid PHPSESSID cookie?
4. What attack does calling session_regenerate_id(true) after login primarily defend against?
5. By default, where does PHP store session data on the server?
Was this page helpful?
You May Also Like
Superglobals and Request Data
Explore PHP's built-in superglobal arrays that expose incoming HTTP request data, server information, and environment variables to every scope without needing to be passed or imported.
PHP Security Basics
Core security practices every PHP developer must apply — input validation, output escaping, safe database access, and secure session handling.
Form Handling and Validation
Learn a reliable pattern for processing submitted HTML forms in PHP: reading input safely, validating and sanitizing each field, and reporting errors back to the user.
Common PHP Pitfalls
A field guide to PHP's most persistent gotchas — loose comparison surprises, array reference bugs, and mutable state traps — and how to avoid them.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics