Mises en garde concernant l’utilisation des cookies

Un inconvénient est que vous savez uniquement ce que fait l’utilisateur, mais vous ne connaissez pas son identité. Si un nouvel utilisateur visite par la suite le même site Web à partir du même ordinateur, il disposera du même accès que le précédent jusqu’à l’expiration de la session.

Du point de vue de la sécurité, la méthode du cookie UUID ne doit pas être considérée comme sécurisée sur les sites Web publics qui ne requièrent pas d’authentification (login). Sur un intranet ou un extranet sécurisé, nécessitant une connexion des utilisateurs, vous pouvez toujours utiliser le gestionnaire cookie-session SQL et vous connaissez l’identité de l’utilisateur à partir du contexte d’une connexion sécurisée.

Si votre site Web requiert l’authentification et la validation des utilisateurs, il est possible de renforcer la sécurité des pages Web en stockant un deuxième UUID dans un autre cookie utilisateur. Liez le deuxième UUID à l’ID utilisateur réel dans la base de données SQL en coulisse, au moyen d’une simple table de conversion, et faites expirer régulièrement le deuxième UUID. Si une personne parvient à lire les cookies sur l’ordinateur de l’utilisateur ou à capturer des paquets provenant de votre site, l’intrus ne verra que des nombres non séquentiels, sans aucune signification. D’ici à ce qu’un utilisateur astucieux découvre le cookie et essaie de l’utiliser pour récupérer des données, il aura probablement expiré et sera inutilisable. Si vos UUID sont conformes aux spécifications publiées et si chacun est réellement unique et universel, ils déjoueront également le jeu consistant à « deviner le prochain ID » car il est impossible d’utiliser un UUID pour en deviner ou en extrapoler mathématiquement un autre. Consultez l’encadré « Ressources supplémentaires » pour une liste des ressources concernant les spécifications.