Les UUID résolvent des problèmes de nommage et de coordination. Ils ne portent ni identité authentifiée, expiration, permissions ou signature. Traiter un identifiant comme capacité transforme chaque fuite, journal, référent ou URL copiée en voie d’accès possible.

Un aspect aléatoire n’implique pas la confidentialité

UUIDv4 possède un grand espace aléatoire s’il est bien généré, mais son but est l’identification à faible collision. UUIDv7 révèle volontairement l’heure de création dans ses 48 premiers bits. Toute valeur peut apparaître dans l’historique, les statistiques, journaux, exports, captures, assistance ou liens. Connaître l’identifiant ne doit jamais suffire pour accéder à l’objet.

Autorisez chaque opération séparément

Après analyse d’un UUID, le serveur doit encore authentifier, charger l’enregistrement dans le bon locataire ou propriétaire et autoriser l’action. Une forme valide ne prouve ni existence ni appartenance. Les erreurs ne devraient pas révéler inutilement l’existence lorsque cela faciliterait l’énumération.

Utilisez des identifiants et jetons dédiés

Les mots de passe exigent un hachage lent et une réinitialisation contrôlée. Les jetons de session ou API exigent entropie, transport sûr, durée, révocation et stockage prudent. Un lien signé authentifie ressource, action et expiration. Un UUID peut participer à ces conceptions, mais son texte seul n’apporte aucune de ces propriétés. UUIDLens génère uniquement des identifiants.