Vos sessions d’application auto-hébergée expirent-elles au bon moment ? Liste de contrôle pratique

Pourquoi le comportement des sessions compte après la connexion

L’authentification établit qu’un utilisateur s’est connecté. La session permet à l’application de le reconnaître lorsqu’il passe d’une page à l’autre ou revient dans l’application. Si une session reste utilisable plus longtemps que prévu, une personne ayant accès au navigateur ou à des identifiants de session copiés peut éventuellement continuer à utiliser le compte.

Un délai configuré ne prouve pas que tous les parcours se terminent comme prévu. La déconnexion, un changement de mot de passe, la désactivation d’un compte et l’authentification unique (SSO) peuvent impliquer différentes parties du système. Évaluez le cycle de vie complet plutôt que de vous fier à un seul paramètre.

L’[OWASP recommande d’appliquer l’expiration des sessions côté serveur et d’invalider une session lorsque l’utilisateur se déconnecte](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html). Le [NIST indique que les cookies de session devraient expirer à la fin de la période de validité de la session ou peu après](https://pages.nist.gov/800-63-4/sp800-63b/session/). Ces recommandations fournissent des points de vérification ; elles ne garantissent pas que toutes les applications offrent les mêmes contrôles.

Distinguer la connexion, la durée de session, le délai d’inactivité et les appareils mémorisés

La connexion est l’étape d’authentification. Une session est la reconnaissance continue, par l’application, de cette connexion. Plusieurs mécanismes peuvent contribuer à la maintenir : la date d’expiration affichée pour un cookie de navigateur ne permet donc pas nécessairement de savoir si le serveur accepte encore la session.

Un délai d’inactivité limite une session après une période sans activité. Une durée maximale de session, parfois appelée durée de vie absolue, limite le temps pendant lequel une session peut rester valide, indépendamment de l’activité. Consultez la documentation et testez le comportement : ne partez pas du principe que l’activité réinitialise une limite absolue ou que l’intitulé « délai d’expiration de session » a partout le même sens.

Une option « Se souvenir de moi » ou de mémorisation de l’appareil peut modifier l’expérience lors d’une visite ultérieure. Vérifiez son effet dans l’application concernée et consignez-le séparément, au lieu de l’assimiler à un délai d’inactivité.

Définir les exigences en fonction des parcours réels et des risques

Choisissez vos exigences en fonction de l’usage de l’application et de ce qu’une session laissée sans surveillance ou toujours valide pourrait exposer. Un poste de travail partagé, l’accès à des dossiers professionnels sensibles ou la possibilité d’effectuer des changements importants peuvent justifier des attentes différentes de celles d’une application utilisée brièvement sur un appareil privé.

Consignez le comportement attendu avant les tests : après une période d’inactivité, à l’expiration de la durée maximale d’une session, après une déconnexion explicite et après la désactivation d’un compte. Définissez également le résultat souhaité après un changement de mot de passe ou un événement SSO, sans supposer que l’application ou le fournisseur d’identité s’en chargera automatiquement.

Les sources citées ne fixent pas une valeur de délai unique pour toutes les applications et tous les parcours. Faites un choix explicite, équilibrant sécurité et facilité d’utilisation, et documentez les exceptions, par exemple une tâche de longue durée qui nécessite une session ouverte.

• Quelles données ou actions sont accessibles, et que permettrait une session sans surveillance ?
• Les utilisateurs travaillent-ils sur des appareils partagés ou laissés sans surveillance ?
• Que doit-il se passer après une période d’inactivité, et quelle durée maximale de session votre organisation accepte-t-elle ?
• Quels événements doivent mettre fin à l’accès : déconnexion, changement de mot de passe, désactivation du compte ou changement chez le fournisseur d’identité ?
• Existe-t-il une option de mémorisation de l’appareil, et son effet convient-il à votre cas d’utilisation ?

Consulter la documentation de l’application pour connaître les contrôles disponibles

Recherchez dans la documentation officielle les termes relatifs à l’expiration de session, au délai d’inactivité, à la durée maximale, à la déconnexion, à la révocation des sessions, aux appareils mémorisés et au SSO. Consultez la documentation correspondant à l’application et à la version utilisées. Ne déduisez pas qu’une fonctionnalité existe parce qu’un produit au nom similaire la propose.

Notez si chaque contrôle est configurable, où il se configure et si la documentation décrit une application côté serveur. Si un parcours n’est pas documenté, indiquez qu’il est inconnu et testez-le ou posez la question au fournisseur ou au responsable de la maintenance. La recommandation de l’OWASP sur l’expiration côté serveur et celle du NIST sur l’expiration des cookies sont des vérifications complémentaires, pas la preuve que l’une garantit l’autre.

Les sources citées ne précisent pas le comportement attendu pour les changements de mot de passe, la désactivation d’un compte, la durée maximale ou les sessions du fournisseur d’identité. Pour ces cas, documentez votre exigence et vérifiez le fonctionnement propre à l’application.

• Consignez la signification documentée de chaque paramètre, notamment si l’activité le réinitialise.
• Recherchez une méthode documentée pour mettre fin aux sessions actives ou les révoquer, et notez sa portée.
• Vérifiez si le comportement diffère entre les comptes locaux et les utilisateurs SSO.
• Conservez le titre de la documentation, sa version ou sa date lorsqu’elle est disponible, ainsi que la date de consultation.

Effectuer des tests pratiques du cycle de vie

Utilisez un compte de test et, dans la mesure du possible, un environnement hors production. Si les tests doivent avoir lieu en production, planifiez-les pour éviter de perturber les utilisateurs ou de modifier l’accès à de vrais comptes. N’utilisez que des données non sensibles et ne partagez pas d’identifiants de session ni d’autres secrets.

Pour tester l’inactivité, connectez-vous, laissez l’application inutilisée pendant l’intervalle configuré, puis essayez d’ouvrir une page protégée ou d’effectuer une action sans conséquence. Testez séparément la durée maximale : maintenez la session active conformément à votre plan et observez si elle prend fin à la limite indiquée. Consignez le temps écoulé et ce que voit l’utilisateur.

Pour tester la déconnexion, déconnectez-vous puis essayez d’accéder à une page protégée dans le même contexte de navigateur. Selon l’OWASP, la session doit être invalidée à la déconnexion. Vérifiez si l’ancienne session permet encore d’accéder à du contenu protégé ; une redirection vers la page de connexion ne suffit pas à elle seule si un autre chemin donne toujours accès à ce contenu.

Testez séparément le changement de mot de passe et la désactivation du compte. Pour chacun, observez si les sessions existantes continuent de fonctionner et comparez le résultat à l’exigence consignée. Les sources citées ne définissent pas de résultat universel obligatoire pour ces cas : ne faites pas de supposition.

Utilisez des actions de test autorisées et sans conséquence. Si le résultat n’est pas clair, répétez le test dans une session de navigateur vierge et consultez la documentation ou le canal d’assistance de l’application.

Répéter les vérifications pour le SSO et les comptes locaux

Si l’application prend en charge la connexion locale et le SSO, testez séparément chaque parcours. L’application et le fournisseur d’identité peuvent avoir des sessions distinctes ; mettre fin à l’une ne prouve pas que l’autre a pris fin. De même, se déconnecter d’une application ne déconnecte pas nécessairement l’utilisateur du fournisseur d’identité.

Pour le SSO, consignez ce qui se passe après la déconnexion de l’application, la déconnexion du fournisseur d’identité, un changement de mot de passe et la désactivation du compte. Vérifiez ce qui arrive lorsque l’utilisateur revient dans l’application ou tente d’utiliser une page déjà ouverte. Répétez les tests pertinents pour les comptes locaux sans extrapoler le comportement SSO.

Si l’application ou le fournisseur d’identité propose des contrôles de révocation des sessions, documentez leur portée et confirmez leur effet lors d’un test. Si le comportement n’est ni documenté ni vérifiable, consignez-le comme une lacune non résolue.

Consigner les attentes et les preuves dans une matrice de test

Une matrice concise rend les vérifications reproductibles. Distinguez le résultat attendu, qui reflète votre politique, du résultat observé pendant le test.

Indiquez l’application et sa version, le parcours d’authentification, la date du test, la configuration concernée, le compte de test, les étapes, le temps écoulé lorsque c’est pertinent, le résultat observé et le statut (réussi, échoué ou non résolu). Mentionnez la documentation consultée et l’action prévue pour combler les lacunes. N’y inscrivez pas de mots de passe, de jetons de session ou d’autres identifiants.

Répétez les vérifications après toute modification importante de la configuration de l’application, de l’authentification ou du déploiement. La fréquence des retests relève d’une décision opérationnelle de votre équipe ; les sources citées ne prescrivent pas de calendrier.

• Inactivité : condition attendue de fin de session, durée testée et disponibilité ou non de l’accès protégé.
• Durée maximale : limite attendue, maintien ou non d’une session active pendant le test, heure de fin et résultat observés.
• Déconnexion : invalidation attendue et résultat lors de la réutilisation du même contexte de navigateur.
• Changement de mot de passe et désactivation du compte : effet attendu et résultat sur les sessions existantes et les tentatives d’accès.
• SSO et connexion locale : testez chaque parcours applicable et consignez la session du système concerné.
• Lacunes : contrôles non documentés, résultats impossibles à vérifier et responsable du suivi.

Attribuer les responsabilités entre l’application, le fournisseur d’identité et l’hébergement

Ne supposez pas qu’un seul intervenant contrôle l’ensemble du cycle de vie des sessions. Associez chaque comportement attendu au composant qui peut le configurer ou le vérifier dans votre déploiement. La répartition exacte dépend de l’application, du fournisseur d’identité, du mode d’hébergement et des accords en place ; les recommandations citées ne répartissent pas ces responsabilités.

Le responsable de l’application doit documenter la politique d’accès, vérifier le comportement de l’application et décider comment traiter les lacunes. Pour le SSO, coordonnez-vous avec l’administrateur du fournisseur d’identité afin de comprendre ses contrôles, puis testez l’expérience combinée. Définissez explicitement la répartition des tâches au lieu de supposer que le SSO ou l’hébergement gère la révocation.

Airbip propose le déploiement géré d’applications de son catalogue sous forme de charges de travail Docker sur des serveurs cloud Airbip. Le service comprend le routage automatisé et des certificats TLS via Traefik et Let’s Encrypt, ainsi que la gestion du cycle de vie des services et des sauvegardes configurables. Ces capacités d’infrastructure ne permettent pas, à elles seules, d’établir le comportement de l’application à l’expiration d’une session ou à la désactivation d’un compte. Vérifiez le comportement au niveau de l’application et convenez de la personne responsable de chaque tâche opérationnelle.

Si l’application ne propose pas un contrôle de session requis, ne considérez pas la gestion de l’infrastructure comme un substitut, sauf si un contrôle documenté et testé répond à l’exigence. Consignez la lacune et décidez s’il faut modifier la configuration, ajouter un contrôle adapté, choisir une autre application ou un autre modèle de déploiement, ou accepter le risque résiduel.

• Désignez la personne responsable de la politique de délai d’expiration et de l’approbation des exceptions.
• Désignez la personne qui configure et teste le comportement des sessions au niveau de l’application.
• Pour le SSO, identifiez l’administrateur du fournisseur d’identité et les comportements qu’il peut confirmer.
• Documentez séparément les tâches d’hébergement, l’accès à l’application et la gouvernance des comptes.
• Suivez chaque comportement non vérifié comme un point en suspens avec une décision ou une action associée.