🛡️web

Les cookies et sessions web : fonctionnement et securite

30 mars 2026 5 min de lecture

Introduction : Pourquoi le web a-t-il besoin de mémoire ?

Imagine que tu navigues sur ton site de streaming préféré. Tu te connectes, tu ajoutes des films à ta liste, tu reprends ta série là où tu l'avais laissée. Mais comment le site se souvient-il de toi entre chaque clic ? Le protocole HTTP, la base du web, est dit « sans état » (stateless). Cela signifie que chaque requête que ton navigateur envoie à un serveur est totalement indépendante de la précédente. Pour créer cette illusion de continuité, les développeurs utilisent deux mécanismes clés : les cookies et les sessions. Dans cet article, on va décortiquer leur fonctionnement, voir comment ils interagissent, et surtout, comment les sécuriser.

Les cookies : les petits fichiers témoins

Un cookie est un petit fichier texte, créé par un site web et stocké sur ton ordinateur par ton navigateur. Il contient des paires clé-valeur (comme username=paul ou lang=fr) et est associé à un domaine spécifique (ex: nsi-lycee.fr). À chaque fois que tu visites ce domaine, ton navigateur envoie automatiquement les cookies correspondants au serveur dans les en-têtes HTTP de la requête.

À quoi servent-ils vraiment ?

  • Gestion de session : L'identifiant unique de ta session (un token) est souvent stocké dans un cookie.
  • Préférences utilisateur : Langue, thème sombre/clair, paramètres d'affichage.
  • Suivi et analyse : Les cookies de suivi (tracking cookies) permettent aux sites de comprendre ton comportement de navigation (souvent pour la publicité).
  • Panier d'achat : Mémoriser les articles que tu as ajoutés avant de passer commande.

Les sessions : la mémoire côté serveur

Contrairement aux cookies stockés chez toi, une session est un espace de stockage temporaire côté serveur. Quand tu te connectes à un site, le serveur crée une session unique pour toi. Il y stocke des données sensibles ou volumineuses qu'il ne veut pas envoyer au client, comme ton nom complet, ton email, ou le contenu de ton panier. Pour faire le lien entre ton navigateur (qui n'a qu'un cookie) et cette session serveur, on utilise un identifiant de session (Session ID). Cet ID, souvent une longue chaîne de caractères aléatoires, est justement stocké dans un cookie sur ta machine. C'est la clé qui permet au serveur de retrouver « ton » espace mémoire à chaque requête.

Exemple en Python (avec Flask)

Voici un exemple simplifié de comment une session peut être gérée :

from flask import Flask, session, request
import os

app = Flask(__name__)
app.secret_key = os.urandom(24) # Clé secrète ESSENTIELLE

@app.route('/login')
def login():
# Après vérification du mot de passe
session['user_id'] = 123 # Stocké côté serveur
return 'Connecté !'

@app.route('/profile')
def profile():
user_id = session.get('user_id') # Récupération via l'ID de session du cookie
if user_id:
return f'Bienvenue utilisateur {user_id}'
return 'Non connecté'

Les risques de sécurité principaux

Ces mécanismes puissants sont aussi des cibles de choix pour les attaquants. Voici les menaces à connaître absolument.

Le vol de session (Session Hijacking)

Si un pirate parvient à voler ton identifiant de session (le cookie session_id), il peut usurper ton identité sur le site. Il n'a même pas besoin de ton mot de passe ! Comment le voler ? Par exemple via une attaque d'homme du milieu sur un réseau Wi-Fi non sécurisé, ou en exploitant une faille XSS (Cross-Site Scripting).

Les attaques XSS (Cross-Site Scripting)

L'attaquant injecte du code JavaScript malveillant dans une page web. Si le site n'est pas bien sécurisé, ce code peut s'exécuter dans le navigateur d'une autre victime et voler ses cookies (surtout ceux non marqués HttpOnly).

Les attaques par fixation de session (Session Fixation)

L'attaquant force une victime à utiliser un identifiant de session qu'il connaît. Quand la victime se connecte, le pirate utilise le même ID pour accéder à son compte.

Les bonnes pratiques de sécurité incontournables

En tant que futur développeur, c'est à toi de mettre en œuvre ces protections.

  • Utilise toujours HTTPS : Crypte les échanges et empêche le vol des cookies en transit. Les cookies sensibles doivent avoir l'attribut Secure.
  • Attribut HttpOnly sur les cookies de session : Rend le cookie inaccessible au JavaScript côté client, bloquant ainsi la majorité des vols par XSS.
  • Attribut SameSite sur les cookies : Empêche les navigateurs d'envoyer le cookie avec des requêtes cross-site, protégeant contre certaines attaques CSRF (Cross-Site Request Forgery).
  • Régénération de l'ID de session : Génère un nouvel ID de session après une élévation de privilèges (ex: connexion). Cela neutralise les attaques par fixation.
  • Expiration courte : Fixe une durée de vie raisonnable aux sessions et aux cookies (session timeout).
  • Stockage sécurisé côté serveur : Ne stocke pas de données sensibles dans le cookie lui-même, mais uniquement dans la session serveur.

Conclusion : Un équilibre entre confort et sécurité

Les cookies et les sessions sont les piliers invisibles de l'expérience web moderne. Ils apportent la « mémoire » indispensable aux sites interactifs. Comprendre leur fonctionnement technique est une étape clé en NSI et pour tout développement web. Mais cette puissance s'accompagne d'une grande responsabilité : celle de les implémenter de manière sécurisée. En appliquant les bonnes pratiques que l'on a vues, tu pourras construire des applications web non seulement fonctionnelles, mais aussi robustes face aux menaces courantes. La sécurité n'est pas une option, c'est une partie intégrante du métier de développeur.

📚 Pour aller plus loin

Questions fréquentes

Où sont physiquement stockés les cookies sur mon ordinateur ?

Cela dépend de ton navigateur et de ton système d'exploitation. Ils sont généralement dans des fichiers de base de données spécifiques (par exemple, pour Chrome sur Windows, dans le dossier `AppData\Local\Google\Chrome\User Data\Default`). En tant qu'utilisateur, tu peux les voir et les gérer dans les paramètres de confidentialité de ton navigateur.

Quelle est la différence entre un cookie et le localStorage ?

Un cookie est envoyé automatiquement au serveur avec chaque requête HTTP vers son domaine, a une taille limitée (~4Ko) et une date d'expiration. Le localStorage est une API JavaScript purement côté client : les données ne sont jamais envoyées automatiquement au serveur, ont une taille plus grande (~5-10Mo) et n'expirent pas. On utilise les cookies pour ce qui intéresse le serveur (session, authentification), et le localStorage pour les préférences purement locales.

Est-ce que les sites peuvent lire tous mes cookies ?

Non, absolument pas. Une règle de sécurité fondamentale, la <strong>Same-Origin Policy</strong>, empêche un site d'accéder aux cookies d'un autre domaine. Le site `nsi-lycee.fr` ne peut lire que les cookies qu'il a lui-même déposés (ou ceux de ses sous-domaines selon les paramètres). C'est pour cela que les boutons de partage sur les réseaux sociaux (Facebook, X) ont besoin de code spécifique pour fonctionner.

Bravo ! Tu as lu cet article
Inscris-toi pour sauvegarder ta progression et gagner des XP
Creer mon compte
cookies sessionsweb securite
Pixel