16. Cookies : transport d’état et confiance

Comprendre le mécanisme

Un cookie est stocké par le navigateur puis envoyé lorsque ses règles d’applicabilité le permettent. Il peut porter un identifiant de session opaque ou une autre donnée, mais son nom et sa présence ne prouvent pas l’autorité de son contenu. Une préférence modifiable et un identifiant authentifié n’ont pas le même rôle. Le serveur décide de l’identité et des droits au moyen d’un mécanisme vérifiable.

Raisonner et vérifier

Inventoriez les cookies, leur finalité et les pages qui les utilisent. Évitez d’y placer inutilement des données personnelles ou des secrets lisibles. Une expiration côté navigateur ne remplace pas la durée d’acceptation de la session côté serveur. Testez déconnexion, changement de privilège et coexistence de cookies portant un même nom avec des portées différentes, afin de repérer les ambiguïtés de lecture.

Identifiant opaque

Un cookie de session peut porter un identifiant opaque. La valeur reçue doit être reliée à un état admis. Un cookie de session peut être une référence aléatoire vers un état serveur. Le nom du cookie ou une valeur role=admin fournie par le client ne constitue pas une preuve de privilège.

Acceptation serveur

Le serveur doit vérifier expiration et retrait de session. Les autres détenteurs ne dépendent pas de cette suppression locale. Le serveur doit vérifier que la session existe, reste active et appartient au contexte attendu. La présence d’un cookie syntaxiquement valide ne suffit pas à lui donner une durée illimitée.

Envoi automatique

Un cookie peut être envoyé automatiquement selon sa politique. L’envoi peut accompagner un déclenchement tiers. Le navigateur joint les cookies selon destination et attributs applicables. Cette automaticité explique le besoin d’une défense CSRF pour les actions sensibles réalisées avec une identité ambiante.

Deux stockages

Le stockage navigateur et l’état serveur sont distincts. Les cycles de conservation peuvent différer. Effacer un cookie retire une copie côté navigateur ; invalider la session retire une capacité côté serveur selon sa politique. Pour une déconnexion sensible, définissez et testez les deux effets.

Portée

Le domaine et le chemin participent au périmètre d’envoi. Ce périmètre ne remplace pas une autorisation métier. Domain et Path influencent les destinations d’envoi. Choisissez une portée minimale, sans en déduire une séparation d’autorisation entre utilisateurs ou une défense suffisante contre un script compromis.

Identité maîtrisée

Une session doit être liée à un état d’identité maîtrisé. Une entrée client ne crée pas un rôle de confiance. La session doit référencer un utilisateur selon le mécanisme serveur, pas faire confiance à des rôles envoyés librement. Rechargez ou versionnez l’état nécessaire à la politique de retrait d’accès.

Canal protégé

Le canal doit protéger les cookies sensibles. Un identifiant opaque volé peut devenir une capacité. Protégez les cookies sensibles avec HTTPS et les attributs adaptés. Vérifiez les terminaisons proxy et évitez qu’une redirection ou un journal conserve leur valeur en clair.

Expiration effective

L’expiration doit être testée côté serveur. Le serveur doit appliquer sa propre décision. Conservez une ancienne valeur dans un test puis présentez-la après expiration serveur. Le refus doit venir de la politique d’acceptation, même si un client malveillant ignore l’expiration navigateur.

Privilège

Les transitions de privilège demandent une politique de session. Le changement d’identité exige une revue de fixation et de rotation. Connexion et élévation de droit sont des transitions qui peuvent exiger rotation et nouvelle authentification. Documentez le devenir des anciennes références afin qu’elles ne gagnent pas silencieusement les nouveaux privilèges.

Journaux

La journalisation doit minimiser les valeurs sensibles. Les traces ne doivent pas devenir un magasin de capacités. Enregistrez événements et références non exploitables plutôt que la valeur de session complète. Une fuite de logs contenant les cookies pourrait créer un accès équivalent à celui que la session protège.

Atelier guidé : lire, expliquer et vérifier le code

Cookie: role=admin; theme=dark

Hypothèse : aucune preuve serveur ne lie role à une identité autorisée.

Le cookie annonce role=admin sans preuve serveur selon l’hypothèse donnée. Cette valeur doit rester une entrée hostile. Remplacez ce modèle par une session ou un token validé puis appliquez une autorisation côté serveur, et vérifiez qu’une modification manuelle du cookie ne donne aucun privilège.

La préférence visuelle ne crée pas de droit. Un client peut présenter une affirmation non fiable. Le nom ne prouve pas l’autorité. Le séparateur ne signe rien.

Travail pratique : Créez une fiche par cookie de laboratoire : finalité, producteur, portée, protections, durée côté navigateur et durée côté serveur.

Critères de correction : Testez une valeur absente, inconnue et révoquée ; vérifiez qu’aucune de ces entrées ne donne un rôle par simple lecture du cookie. Contrôlez ensuite que la déconnexion invalide le contexte selon le contrat prévu.