--- term: 'Gestion des Sessions' seoTitle: 'Gestion des sessions : cycle de vie, cookies, hijacking, timeouts' headline: "Qu'est-ce que la gestion des sessions ?" slug: gestion-des-sessions category: auth-security shortDefinition: 'La gestion des sessions est une discipline qui consiste à créer, valider et détruire l''état côté serveur reliant les requêtes HTTP à un utilisateur.' relatedTerms: - json-web-token-jwt - authentication-vs-authorization - cross-site-scripting-xss-prevention - multi-factor-authentication-mfa contrastsWith: - json-web-token-jwt aboutTerms: - 'ID de Session' - 'Détournement de Session (Session Hijacking)' - 'Fixation de Session (Session Fixation)' - 'Cookies de Session' faq: - question: 'Comment fonctionnent les sessions ?' answer: "À la connexion, le serveur crée un enregistrement de session et émet un ID aléatoire dans un cookie ; le navigateur renvoie cet ID à chaque requête, le serveur retrouve l'état associé, et l'enregistrement est détruit à la déconnexion ou à l'expiration. L'ID est la totalité de l'identifiant — quiconque le présente est traité comme l'utilisateur." - question: "Quelle est la différence entre l'authentification par session et par token (JWT) ?" answer: "L'endroit où vit l'état. Les sessions le gardent côté serveur — une recherche par requête, révocable instantanément. Les JWT le transportent dans le token — aucune recherche, vérifiable partout, mais valide jusqu'à expiration quoi qu'il arrive. Les sessions conviennent aux applications mono-domaine qui veulent du contrôle ; les tokens, aux API et aux microservices qui veulent de la portabilité." - question: "Qu'est-ce que le détournement de session (session hijacking) et comment le prévenir ?" answer: "Voler un ID de session valide — par sniffing, XSS ou malware — et le présenter pour usurper l'identité de l'utilisateur sans jamais connaître son mot de passe. Défenses : HTTPS partout, flags HttpOnly et Secure sur le cookie, ID à forte entropie, durées de vie courtes, régénération à chaque changement de privilège et supervision des anomalies." - question: "Qu'est-ce que la fixation de session (session fixation) ?" answer: "L'attaquant plante un ID de session qu'il connaît déjà — via un lien fabriqué ou un cookie de sous-domaine — et attend que la victime se connecte avec lui ; l'ID connu devient alors une session authentifiée. La correction complète : émettre un ID entièrement nouveau à chaque événement d'authentification et rejeter les ID que le serveur n'a jamais générés." - question: 'À quoi servent les flags du cookie de session ?' answer: "Chacun ferme une voie de vol : Secure n'envoie le cookie que sur HTTPS (contre le sniffing) ; HttpOnly le cache à JavaScript (contre le vol de cookie par XSS) ; SameSite le retient sur les requêtes cross-site (contre le CSRF) ; et le préfixe de nom __Host- le verrouille sur une seule origine." - question: 'Quel est le bon timeout de session ?' answer: "Deux horloges, toutes deux imposées par le serveur : un timeout d'inactivité — quelques minutes pour les applications à forte valeur, 15–30 pour les cas courants — et un timeout absolu de quelques heures, indépendamment de l'activité. Le référentiel fédéral d'identité numérique, à son deuxième niveau d'assurance, recommande au plus 1 heure d'inactivité et une réauthentification au moins toutes les 24 heures." - question: 'Comment la déconnexion doit-elle fonctionner ?' answer: "Côté serveur d'abord : détruisez l'enregistrement de session pour que l'ID meure partout, puis seulement effacez le cookie. L'échec classique est l'inverse — supprimer le seul cookie laisse la session vivante pour quiconque a capturé l'ID, ce qui réduit la \"déconnexion\" à une animation d'interface." - question: 'Le "se souvenir de moi" est-il sûr ?' answer: "C'est un échange délibéré de sécurité contre du confort. Fait correctement : un token distinct à longue durée de vie, à usage unique et tourné à chaque visite, stocké dans un cookie durci, révocable côté serveur, invalidé au changement de mot de passe — et jamais un substitut à la réauthentification avant une action sensible." codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'OWASP Session Management Cheat Sheet' url: 'https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html' - name: 'NIST SP 800-63B-4 §5 — Session Management' url: 'https://pages.nist.gov/800-63-4/sp800-63b.html' - name: 'RFC 6265 — HTTP State Management Mechanism' url: 'https://datatracker.ietf.org/doc/html/rfc6265' - name: 'Using HTTP cookies — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies' cta: title: 'Des sessions que vous pouvez interroger' text: "Sur Back4app, les sessions sont des objets de base de données — par appareil, listables pour un écran \"sessions actives\" et révocables côté serveur à l'instant où un utilisateur se déconnecte, change son mot de passe, ou dès que vous le décidez." linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-10' translationKey: session-management --- **La gestion des sessions est une discipline qui consiste à créer, valider et détruire l'état côté serveur reliant les requêtes HTTP à un utilisateur.** HTTP en lui-même ne se souvient de rien — chaque requête arrive en inconnue — alors les applications comblent l'écart avec une session : un enregistrement côté serveur plus un ID aléatoire que le navigateur présente à chaque requête. L'idée de sécurité dont tout le reste découle : **cet ID équivaut à un identifiant complet** — quiconque le détient *est* l'utilisateur, sans mot de passe — il mérite donc une génération, un transport et une destruction de qualité mot de passe. ## Points clés | Question | Réponse | | --- | --- | | Le mécanisme | Connexion → enregistrement serveur + ID aléatoire dans un cookie → ID renvoyé à chaque requête | | L'idée | L'ID de session *est* un identifiant — ID détourné = compte pris | | Le cycle de vie | Créer → régénérer à la connexion/au changement de privilège → valider → expirer → détruire côté serveur | | Les chiffres | ≥64 bits d'entropie CSPRNG · 15–30 min d'inactivité · quelques heures en absolu | | Le bug classique | Une "déconnexion" qui supprime le cookie mais laisse vivant l'enregistrement serveur | ## Le cycle de vie en cinq étapes ```text 1 CRÉER à la connexion : enregistrement côté serveur + ID aléatoire tout neuf (≥64 bits, CSPRNG) 2 RÉGÉNÉRER à CHAQUE changement de privilège — connexion, élévation de rôle, changement de mot de passe — émettez un nouvel ID, retirez l'ancien (tue la fixation) 3 VALIDER à chaque requête : l'ID existe, n'a pas expiré, correspond bien à cet utilisateur 4 EXPIRER deux horloges, imposées par le serveur : timeout d'inactivité + timeout absolu 5 DÉTRUIRE déconnexion = supprimez l'enregistrement serveur D'ABORD, puis effacez le cookie (une "déconnexion" limitée au cookie laisse la session vivante pour un voleur) ``` Les sessions comme objets de première classe, interrogeables — le cycle de vie avec des poignées : **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Sessions are objects: queryable, per-device, revocable const user = await Parse.User.logIn('ada', password); // Session object created console.log(user.getSessionToken()); // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) const sessions = await new Parse.Query(Parse.Session).find(); // Logout = server-side destroy — the token dies NOW await Parse.User.logOut(); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Sessions are objects: queryable, per-device, revocable final user = ParseUser('ada', password, null); await user.login(); // Session object created print(user.sessionToken); // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) final sessions = await QueryBuilder(ParseSession.forQuery()).query(); // Logout = server-side destroy — the token dies NOW await user.logout(); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Sessions are objects: queryable, per-device, revocable let user = try await User.login(username: "ada", password: password) print(user.sessionToken ?? "") // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) let sessions = try await ParseSession.query().find() // Logout = server-side destroy — the token dies NOW try await User.logout() ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Sessions are objects: queryable, per-device, revocable val user = ParseUser.logIn("ada", password) // Session object created println(user.sessionToken) // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) val sessions = ParseQuery.getQuery(ParseSession::class.java).find() // Logout = server-side destroy — the token dies NOW ParseUser.logOut() ``` ```mermaid flowchart LR accTitle: Cycle de vie de la session, de la connexion à la destruction côté serveur accDescr: À la connexion, le serveur crée un enregistrement de session et émet un ID aléatoire dans un cookie. L'ID est régénéré à chaque changement de privilège, validé à chaque requête contre l'enregistrement serveur, expiré par les timeouts d'inactivité et absolu, puis détruit côté serveur à la déconnexion pour que l'ID meure partout. L["Connexion
(authentification)"] --> C["Créer l'enregistrement +
ID aléatoire → cookie"] C --> R["Régénérer l'ID au
changement de privilège"] R --> V["Valider à
chaque requête"] V -->|"timeout d'inactivité
/ absolu"| X["Expirer"] V -->|"déconnexion"| D["Détruire l'enregistrement
côté serveur"] X --> D ``` ## Cookies de session : les flags, et ce que chacun bloque La correspondance qu'aucune page de classement ne tabule — chaque flag est la pierre tombale d'une attaque nommée : | Flag | Ce qu'il fait | Attaque bloquée | | --- | --- | --- | | `Secure` | Le cookie ne circule que sur HTTPS | Sniffing réseau | | `HttpOnly` | Invisible pour JavaScript | Vol de cookie par [XSS](/glossary/fr/prevention-xss/) | | `SameSite=Lax/Strict` | Retenu sur les requêtes cross-site | CSRF | | Préfixe `__Host-` | Verrouille le cookie sur l'origine, sans ruse de sous-domaine | Fixation via sous-domaines | | *(sans Max-Age/Expires)* | Meurt avec la session du navigateur | Sessions périmées sur machine partagée | Sémantique conforme à la [RFC 6265](https://datatracker.ietf.org/doc/html/rfc6265), avec les détails pratiques sur [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies). Les cinq ensemble constituent la ligne de base, pas la configuration durcie. ## Les attaques, chacune avec sa défense **Détournement (hijacking)** — voler un ID valide (sniffing sur HTTP en clair, XSS, malware) et le présenter ; le serveur voit l'utilisateur. Défense : TLS partout, le tableau de flags ci-dessus, des durées de vie courtes, la supervision des voyages impossibles. **Fixation** — l'inversion qui vaut d'être comprise mécaniquement : l'attaquant *donne* à la victime un ID avant la connexion (lien fabriqué, cookie planté) ; la victime s'authentifie ; l'ID que l'attaquant connaît est désormais une session connectée. Défense en un seul geste : **régénérez l'ID à l'authentification** — l'ID pré-connexion que l'attaquant connaît devient sans valeur à l'instant où les privilèges s'y attachent, et les serveurs stricts rejettent tout ID qu'ils n'ont pas frappé eux-mêmes. **Vol par XSS** — le script injecté lit le cookie ; `HttpOnly` supprime cette lecture, ce qui est une limitation des dégâts pendant que [le XSS lui-même est corrigé](/glossary/fr/prevention-xss/). **CSRF** — le navigateur, serviable, attache les cookies aux requêtes cross-site forgées ; `SameSite` plus des tokens anti-CSRF referment la porte. ## Sessions vs. JWT | | Sessions côté serveur | JWT | | --- | --- | --- | | Où vit l'état | Sur le serveur | Dans le token | | Révocation | Instantanée — supprimez l'enregistrement | Attend `exp`, ou un état de denylist | | Coût par requête | Une recherche dans le store | Vérification de signature | | Mise à l'échelle entre services | Exige un store partagé | Tout détenteur de la clé vérifie | Le point crucial est la **révocabilité**, et c'est une décision d'architecture, pas une case à cocher de fonctionnalité : les sessions peuvent mourir au moment où vous le décidez ; les tokens sans état ne le peuvent pas, et chaque contournement réintroduit l'état que vous aviez retiré. [L'article sur les JWT](/glossary/fr/json-web-token-jwt/) défend le camp sans état ; le sujet de cet article est ce qu'exige un stateful fait *correctement*. ## Les chiffres qui rendent la chose concrète [La cheat sheet d'OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) fixe l'entropie à **≥64 bits issus d'un CSPRNG** — seize caractères hexadécimaux aléatoires, assez pour que forcer les ID prenne des siècles à des débits de requêtes réalistes — sans rien de signifiant encodé dans l'ID. Les timeouts tournent sur deux horloges : **inactivité** (2–5 minutes pour les applications à forte valeur, 15–30 pour les cas courants) et **absolu** (quelques heures, mettant fin même aux sessions actives pour qu'un ID volé ait un plafond dur). [Les lignes directrices d'identité numérique du NIST](https://pages.nist.gov/800-63-4/sp800-63b.html) formalisent la même forme : au niveau d'assurance 2, réauthentification après au plus 1 heure d'inactivité et au moins toutes les 24 heures (12 heures au niveau 3), quoi qu'il arrive. ## Mettre les sessions à l'échelle : sticky routing vs. store partagé | | Sticky sessions | Store partagé (style Redis) | | --- | --- | --- | | Comment | Le load balancer épingle utilisateur → serveur | Tous les serveurs lisent un seul session store | | Le serveur meurt | Ses sessions meurent avec lui | Les utilisateurs ne s'en aperçoivent pas | | Mise à l'échelle | Charge déséquilibrée, drain à chaque déploiement | N'importe quel serveur, n'importe quelle requête | | Verdict | Une rustine de routage | L'architecture | La mémoire de session in-process ne fonctionne que sur un seul serveur. Le sticky routing l'étire — et transforme chaque serveur en petite panne en attente de déconnecter des utilisateurs. La réponse standard est un store partagé en mémoire (Redis, Memcached) ou la base de données : l'état de session devient de l'infrastructure, et la couche web devient sans état — la propriété même qui rend les architectures JWT attirantes, obtenue tout en gardant la révocation instantanée. ## Les sessions comme fonctionnalité produit La couche de sécurité fait aussi office d'UX quand les sessions sont *visibles* : un écran "sessions actives" listant chaque appareil avec son heure et son lieu de connexion, un bouton "se déconnecter partout", et la révocation automatique de toutes les sessions au changement de mot de passe ou en cas de compromission suspectée. Les utilisateurs y lisent de la sûreté ; les ingénieurs devraient y lire une exigence sur l'architecture — les sessions doivent être des *objets interrogeables avec un propriétaire*, pas des blobs opaques dans un cache, ce qui est précisément là où les session stores conçus pour la seule recherche échouent. ## Cas d'usage courants - **État de connexion d'une application web** — le cas canonique : des sessions portées par cookie avec le jeu complet de flags. - **Paniers et parcours e-commerce** — un état multi-étapes qui doit survivre à la navigation, mais pas à la semaine. - **Banque et applications à forte valeur** — timeouts d'inactivité courts, plafonds absolus, [MFA de step-up](/glossary/fr/authentification-multifacteur-mfa/) en cours de session pour les actions sensibles. - **Gestion d'appareils** — des sessions par appareil qui alimentent le "déconnecter mon téléphone volé". - **Interfaces d'administration** — là où la régénération à l'élévation de privilège et des timeouts agressifs gagnent leur place. ## Devriez-vous utiliser des sessions ou des tokens ? Matrice de décision | Situation | Choisissez | | --- | --- | | Application web mono-domaine | Les sessions — plus simples et révocables instantanément | | Le verrouillage instantané est non négociable | Les sessions (ou des tokens + l'état que vous vouliez éviter) | | De nombreux services vérifient indépendamment | Les [JWT](/glossary/fr/json-web-token-jwt/) | | Application mobile sur un BaaS | Les session tokens de la plateforme — révocables, déjà construits | | Mise à l'échelle horizontale avec sessions | Un store partagé, pas du sticky routing | | Les "appareils actifs" comme fonctionnalité | Des sessions comme objets interrogeables | ## Limites et trade-offs - **Le store est de l'infrastructure sur le chemin critique.** Chaque requête le lit ; sa latence est votre latence, sa panne est la déconnexion de tout le monde. - **Le cross-domain est inconfortable.** Les cookies s'attachent aux origines ; une API consommée par de nombreuses parties pousse vers les tokens — l'hybride honnête est souvent : sessions pour l'application, tokens pour l'API. - **Les timeouts taxent les utilisateurs.** Chaque déconnexion par inactivité est une friction ; les chiffres ci-dessus sont des décisions de risque, pas des constantes, et méritent un arbitrage produit. - **La révocation exige une plomberie que l'utilisateur voit.** La révocation instantanée n'a de valeur que si le changement de mot de passe et le "se déconnecter partout" la déclenchent vraiment — câblez les événements, pas seulement la capacité. - **Les sessions héritent de la politique des cookies.** Les évolutions sur les cookies tiers et les travaux de confidentialité des navigateurs déplacent sans cesse le terrain ; les cookies de session first-party restent un sol sûr, mais restez-y délibérément. ## Gestion des sessions sur Back4app Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Les sessions y sont les "objets interrogeables" que cet article ne cesse de réclamer — littéralement : chaque connexion crée un objet `Session` qui porte le token révocable, son utilisateur, le contexte de création et l'expiration, cadré par ACL pour que chacun ne voie que les siennes. Les onglets de code en montrent les conséquences : un écran "appareils actifs" est une requête ; la déconnexion est un destroy côté serveur qui tue le token partout immédiatement ; un changement de mot de passe peut révoquer toutes les sessions ; et les triggers Cloud Code sont le point d'accroche pour les règles de step-up et les journaux d'audit. Cycle de vie, révocation et fonctionnalités produit reposent sur la même primitive — les sessions comme données — avec la machinerie d'entropie, de stockage et de validation opérée par la plateforme.