Sessions et cookies

Le problème : HTTP est sans mémoire

Chaque requête HTTP est indépendante. Le serveur ne sait pas que la personne qui visite la page 2 est la même que celle qui était sur la page 1. C'est comme si chaque fois que vous ouvriez une porte dans le bâtiment, la plomberie oubliait qui vous êtes.

Les sessions et les cookies résolvent ce problème en créant une mémoire entre les pages.

Les sessions : mémoire côté serveur

Une session stocke des données sur le serveur, liées à un visiteur via un identifiant unique :

// TOUJOURS en première ligne du fichier (avant tout HTML)
session_start();

// Stocker des données
$_SESSION['utilisateur'] = 'Alice';
$_SESSION['role'] = 'admin';
$_SESSION['connecte'] = true;

// Lire des données (sur une autre page)
session_start();
echo $_SESSION['utilisateur'];  // → Alice

// Supprimer une donnée
unset($_SESSION['role']);

// Détruire toute la session (déconnexion)
session_destroy();

Important : session_start() doit être appelé avant tout output HTML, sinon PHP affiche une erreur « headers already sent ».

Sous le capot : où vivent les données ?

Un serveur, c'est une machine (souvent distante) qui fait tourner PHP et qui peut écrire des fichiers. Quand tu appelles session_start(), voici ce qui se passe vraiment :

1. Au premier passage, PHP génère un identifiant unique (ex. PHPSESSID = a1b2c3…) et crée un fichier sur le serveur pour ce visiteur (typiquement /tmp/sess_a1b2c3…, ou une entrée en base de données).
2. Il renvoie cet identifiant au navigateur dans un cookie. C'est la seule chose qui voyage : pas tes données, juste l'étiquette.
3. À chaque requête suivante, le navigateur renvoie automatiquement ce cookie. PHP lit l'ID, ouvre le bon fichier, et remplit $_SESSION avec son contenu.

D'où deux choses que tu n'as plus besoin d'apprendre par cœur : tu les retrouves par la logique.

• « headers already sent » : déposer le cookie de session est un en-tête HTTP, et les en-têtes partent avant le contenu de la page. Donc session_start() doit s'exécuter avant le moindre caractère de HTML (même un espace ou une ligne vide avant <?php).
• L'expiration : comme les fichiers de session s'accumulent, le serveur les nettoie régulièrement. Une session inactive finit donc par disparaître, c'est normal.

Les cookies : mémoire côté navigateur

Un cookie est un petit fichier stocké dans le navigateur de l'utilisateur :

// Créer un cookie (expire dans 30 jours)
setcookie("theme", "dark", time() + (30 * 24 * 3600), "/");

// Lire un cookie
$theme = $_COOKIE['theme'] ?? 'light';
echo "Thème actuel : $theme";

// Supprimer un cookie (date dans le passé)
setcookie("theme", "", time() - 3600, "/");

Sessions vs Cookies :

• Session : les données vivent sur le serveur ; c'est le cookie d'identifiant qui s'efface à la fermeture du navigateur, donc la session devient inaccessible (les données serveur, elles, sont nettoyées un peu plus tard par le serveur)
• Cookie : données sur le navigateur, peut durer des jours/mois

Règle : les données sensibles (login, rôle, ID) vont en session. Les préférences (thème, langue) vont en cookie.

Exemple : flux de connexion

// login.php
session_start();

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $email = $_POST['email'] ?? '';
    $password = $_POST['password'] ?? '';

    // Vérifier en base de données (simplifié ici)
    if ($email === 'alice@exemple.fr' && password_verify($password, $hash_stocke)) {
        // Connexion réussie
        $_SESSION['user_id'] = 42;
        $_SESSION['user_nom'] = 'Alice';
        session_regenerate_id(true); // Sécurité !
        header('Location: /dashboard.php');
        exit;
    } else {
        $erreur = "Email ou mot de passe incorrect.";
    }
}

// dashboard.php
session_start();

if (empty($_SESSION['user_id'])) {
    header('Location: /login.php');
    exit;
}

echo "Bienvenue, " . htmlspecialchars($_SESSION['user_nom']);

// logout.php
session_start();
$_SESSION = [];
session_destroy();
header('Location: /login.php');

Sécurité des sessions

• session_regenerate_id(true) : après le login, pour éviter le « session fixation »
• Cookies HttpOnly : empêche JavaScript d'accéder au cookie de session
• Cookies Secure : le cookie n'est envoyé qu'en HTTPS
• SameSite=Strict : protège contre les attaques CSRF

// Configuration sécurisée des cookies de session
ini_set('session.cookie_httponly', 1);
ini_set('session.cookie_secure', 1);
ini_set('session.cookie_samesite', 'Strict');
session_start();

// Ou avec setcookie() pour vos propres cookies
setcookie("theme", "dark", [
    'expires'  => time() + 86400 * 30,
    'path'     => '/',
    'httponly'  => true,
    'secure'   => true,
    'samesite' => 'Strict'
]);

Ces trois réglages, concrètement, qu'est-ce qu'ils empêchent ? Ton cookie de session est une clé : qui le possède est connecté en tant que toi. Chacun de ces drapeaux ferme une façon différente de te voler cette clé.

• HttpOnly : le cookie devient invisible au JavaScript. Il reste dans le navigateur et part bien à chaque requête, mais un script de la page ne peut plus le lire (document.cookie ne le voit pas). Pourquoi ? Si un attaquant réussit à injecter du JavaScript dans ta page (une faille XSS), son script pourrait sinon copier ton cookie et l'envoyer ailleurs : l'attaquant le colle dans son navigateur et se retrouve connecté à ta place. HttpOnly mure le cookie, seul le navigateur y touche pour l'envoyer.
• Secure : le cookie ne circule jamais en clair. Ce cookie traverse le réseau à chaque requête. Sur une connexion http:// (non chiffrée), n'importe qui sur le même réseau (un wifi public, un équipement entre toi et le serveur) peut lire ce qui passe et récupérer ton identifiant de session. Secure ordonne au navigateur de n'envoyer ce cookie qu'en https:// (chiffré), il ne voyage donc jamais lisible.
• SameSite=Strict : le cookie n'est pas envoyé quand la requête vient d'un autre site. Par défaut, le navigateur colle automatiquement ton cookie de session sur toute requête vers ton site, même déclenchée depuis une autre page. C'est la faille CSRF : tu es connecté à ta banque, tu ouvres un site piégé qui contient un formulaire caché vers tabanque.com/virement ; ton navigateur y joint ton cookie, et la banque croit que l'ordre vient de toi. SameSite=Strict ajoute la règle : n'attache ce cookie que si la requête part de mon propre site. Une requête lancée depuis ailleurs arrive donc sans cookie, donc non authentifiée, donc ignorée.

À vous d'essayer

On simule $_SESSION avec un simple tableau pour voir la logique de connexion. Modifiez, puis exécutez :

<?php
// Simulation de $_SESSION (un vrai $_SESSION exige session_start())
$session = [];

// Connexion : on stocke l'utilisateur
$session['user_id']  = 42;
$session['user_nom'] = 'Alice';
$session['role']     = 'admin';

// Sur une autre page : on verifie l'acces
if (empty($session['user_id'])) {
    echo "Acces refuse : connectez-vous.";
} else {
    echo "Bienvenue, " . htmlspecialchars($session['user_nom']) . "\n";
    echo "Role : " . $session['role'];
}
?>