Outils de développement · Générateur UUID
Pourquoi crypto.randomUUID() échoue sur les pages HTTP : explication des contextes sécurisés
· Comment ça marche
uuid cryptographie API du navigateur
crypto.randomUUID fonctionne sur localhost et sur HTTPS, puis disparaît sur un hôte intermédiaire HTTP simple. Cet article explique la règle de contexte sécurisé derrière ce comportement et comment générer un UUID en toute sécurité là où il s'applique.
TypeError lors de la mise en scène, très bien partout ailleurs - le symptôme et la différence d'environnement qui le provoque
Un développeur vérifie son travail sur localhost:3000 et le générateur UUID fonctionne parfaitement. Ils se déploient sur le site http://staging. interne. exemple. com (HTTP simple sur le réseau local de l'entreprise) et le code renvoie TypeError : crypto.randomUUID n'est pas une fonction. Le même code en production sur https://example. com fonctionne très bien. L'incohérence est déconcertante jusqu'à ce qu'ils lisent la documentation MDN : crypto.randomUUID est limité aux contextes sécurisés. Un contexte sécurisé est soit HTTPS, soit localhost ; une origine HTTP simple sur un réseau local n'est pas sécurisée par la règle du navigateur, même si le réseau est privé. Le correctif consiste à utiliser crypto.getRandomValues avec des opérations manuelles sur les bits ou à mettre à niveau le serveur intermédiaire vers HTTPS. La règle de contexte sécurisé a été introduite pour empêcher les API sensibles de fuir vers des connexions non chiffrées.
Qu'est-ce qu'un contexte sécurisé : la règle du navigateur qui réserve certaines API aux origines HTTPS et à localhost
Une page sur HTTP simple peut être interceptée par un attaquant réseau ; exposer des API cryptographiques à une telle page permettrait à un attaquant de générer des identifiants à l'aide d'une API compromise. HTTPS crypte la page et toutes les communications API afin qu'un attaquant sur le réseau ne puisse pas intercepter ou modifier le code. Localhost est traité comme intrinsèquement sécurisé car il n'existe que sur la machine locale et ne peut pas être intercepté sur le réseau. Toute autre origine HTTP (une adresse LAN, un domaine public sans HTTPS, un proxy inverse qui transmet vers HTTP) n'est pas sécurisée par définition. L'API Web Crypto est divisée en deux fonctions : crypto.randomUUID, limitée aux contextes sécurisés, et crypto.getRandomValues, disponible dans des contextes sécurisés et non sécurisés. Les deux utilisent le même système d’exploitation CSPRNG.
Quelles parties de Web Crypto sont fermées : crypto.randomUUID et crypto.subtle nécessitent un contexte sécurisé, contrairement à crypto.getRandomValues.
La différence est que getRandomValues ne cache pas le fait que vous utilisez la cryptographie ; une page qui l'utilise doit demander explicitement des octets aléatoires. La fonction randomUUID est pratique et applique également un contexte sécurisé. Si votre application doit générer des UUID sur une page non sécurisée, vous devez utiliser getRandomValues et définir manuellement les bits de version et de variante. RFC 9562 spécifie les opérations sur les bits : définir l'octet 6 sur (byte6 & 0x0f) | 0x40 pour la version 4 et l'octet 8 vers (byte8 & 0x3f) | 0x80 pour la variante RFC. La bibliothèque ToolAcre fait exactement cela comme solution de secours lorsque randomUUID n'est pas disponible. Reproduire l'échec : servir une page simple à partir d'une simple origine HTTP qui n'est pas considérée comme potentiellement digne de confiance. Vérifiez si randomUUID est exposé, puis comparez getRandomValues, ce que la référence Web Crypto autorise dans des contextes non sécurisés.
Création d'un UUID v4 à partir de getRandomValues - la solution de secours de masquage et de formatage qui vous maintient sur le CSPRNG lorsque randomUUID est manquant
Le même code dans un fichier diffusé via HTTPS peut exposer un UUID aléatoire. Si la production signale « randomUUID n'est pas une fonction », vérifiez d'abord si l'origine est un contexte sécurisé, puis vérifiez la prise en charge du navigateur et si un autre script a remplacé l'objet cryptographique. Le remède peut être HTTPS ou une implémentation getRandomValues qui définit explicitement les bits UUID. Un polyfill Math.random n'est pas une solution de secours équivalente : il reproduit la forme tout en supprimant le contrat source cryptographique. Les tests qui n'affirment que des tirets et des chiffres de version manqueront cette substitution, alors examinez le chemin source ainsi que la chaîne résultante.
Exemple fonctionnel — reproduisant l'échec sur une origine http:// et confirmant le correctif
Mais l'identifiant est désormais prévisible. Un attaquant qui capture quelques UUID de votre système peut prédire le suivant. Si une application traite par erreur un tel identifiant comme un titre de porteur, la prévisibilité devient un échec d’autorisation plutôt qu’un défaut esthétique. La stratégie correcte consiste à mettre à niveau le serveur vers HTTPS (toujours la bonne solution pour toute page contenant des données d'authentification ou sensibles) ou à utiliser getRandomValues avec des opérations binaires explicites (ce qui prend plus de code mais est cryptographiquement solide). Le contexte sécurisé est appliqué par le navigateur ; vous ne pouvez pas contourner ce problème avec des variables de configuration ou d'environnement. Le générateur ToolAcre est déployé via HTTPS, donc crypto.randomUUID est disponible. Lorsque vous générez un UUID dans l'outil, il utilise soit randomUUID (si la vérification du contexte sécurisé réussit), soit getRandomValues avec des opérations sur bits (si vous êtes sur HTTP simple, bien que cela soit rare).
Pourquoi vous ne devriez pas polyfill avec Math.random - le raccourci tentant et le coût de sécurité qu'il entraîne
Aucun des deux chemins ne revient à Math.random. Si vous créez votre propre générateur UUID et ciblez des origines non sécurisées, utilisez getRandomValues et effectuez les opérations sur les bits vous-même. Testez à la fois sur HTTPS et localhost pour confirmer que randomUUID fonctionne, puis testez sur une origine http:// pour confirmer que votre solution de secours getRandomValues est correcte. Comprendre la restriction du contexte sécurisé vous aide à concevoir des stratégies de déploiement. Si votre application doit s'exécuter sur un réseau local privé sans HTTPS (infrastructure héritée, systèmes embarqués), la solution de secours getRandomValues est votre voie à suivre. Si vous avez le choix, passez au HTTPS partout ; c'est gratuit avec Let's Encrypt, et l'investissement est récompensé en termes de sécurité sur l'ensemble de l'application. Le développement sur localhost n'a aucune restriction, alors testez votre générateur UUID sur localhost et sur le staging HTTPS avant de le déployer en production. La production doit toujours être HTTPS.
Ce que cela ne couvre pas : les environnements d'exécution de serveur tels que Node.js et Deno, qui exposent l'API sans règle de contexte sécurisé
La restriction n'est pas un bug ou une nuisance ; c'est un élément de sécurité qui évite les accidents et oblige à penser au cryptage. Le modèle le plus large est que les API de cryptographie Web sont contrôlées par un contexte sécurisé. crypto.getRandomValues, crypto. subtil. chiffrer, chiffrer. subtil. generateKey et toutes les autres opérations sensibles nécessitent HTTPS ou localhost. Il n'y a aucune exception, aucune dérogation, aucun moyen de désactiver la vérification. Une seule page non sécurisée brise les garanties de sécurité de vos utilisateurs. Même si vous veillez à n'utiliser les API de chiffrement que sur certaines pages, une erreur (ou une dépendance incluant un générateur UUID) peut entraîner une fuite de génération aléatoire vers une page non chiffrée. Le générateur ToolAcre applique cela au niveau du code : si randomUUID n'est pas disponible (contexte non sécurisé), il utilise getRandomValues, qui est disponible mais alerte tout réviseur de code que quelque chose d'inhabituel se produit.
À retenir : corrigez l'origine, pas le générateur – ToolAcre est servi via HTTPS, de sorte que son générateur s'exécute dans un contexte sécurisé dès sa conception
Mieux encore, il refuse de générer un identifiant si le contexte sécurisé est réellement indisponible (dans les environnements où getRandomValues n'est pas non plus disponible, ce qui est rare mais possible dans les systèmes anciens ou embarqués). La migration d'un système existant vers HTTPS pour prendre en charge les API de cryptographie sécurisée est un projet courant. Commencez par l'origine où les UUID sont générés (votre serveur d'authentification, votre backend API ou votre service d'application clé). Acquérir un certificat TLS (Let's Encrypt les fournit gratuitement). Configurez votre serveur Web pour qu'il serve HTTPS par défaut et redirigez les requêtes HTTP vers HTTPS. Testez avec plusieurs navigateurs et clients API pour vous assurer que tout fonctionne. Vérifiez ensuite votre code pour détecter toutes les API de chiffrement restantes qui pourraient être appelées sur des pages non chiffrées et corrigez-les. Le générateur ToolAcre suppose HTTPS ; si vous l'utilisez, vous avez déjà fait une partie du chemin.