Skip to main content
Tous les termes Glossary

Web Crypto API

Definition

Web Crypto API fournit une interface standardisée pour effectuer des opérations cryptographiques dans les applications Web. Elle offre des fonctionnalités sécurisées de génération de nombres aléatoires, de hachage, de signature et de chiffrement. Bien que plus sûr que la mise en œuvre de la cryptographie dans JavaScript, une gestion appropriée des clés et une sélection judicieuse des algorithmes restent essentielles.

Qu'est-ce que la Web Crypto API

La Web Crypto API est une interface native du navigateur, exposée via window.crypto et crypto.subtle, permettant d'effectuer des opérations cryptographiques en JavaScript. Elle couvre la génération de valeurs aléatoires cryptographiquement fortes via getRandomValues, ainsi que le hachage, le HMAC, le chiffrement symétrique et asymétrique, les signatures numériques et la dérivation de clés via l'objet SubtleCrypto. Les primitives sont implémentées dans le moteur du navigateur en code natif plutôt qu'en script, ce qui est plus rapide et moins sujet aux erreurs qu'une cryptographie JavaScript faite maison. Les clés sont représentées sous forme d'objets CryptoKey qui peuvent être marqués comme non extractibles, de sorte que le matériel de clé brut n'a jamais à être exposé au JavaScript environnant. La majeure partie de l'API est restreinte aux contextes sécurisés, c'est-à-dire aux pages servies via HTTPS ou depuis localhost.

Pourquoi c'est important pour la sécurité

S'appuyer sur une implémentation native éprouvée élimine des catégories entières de bugs qui affligent la cryptographie JavaScript maison, comme les sources aléatoires faibles, les fuites temporelles et un branchement d'algorithme incorrect. Les objets CryptoKey non extractibles font que même un script s'exécutant sur la page ne peut pas lire les octets sous-jacents, ce qui limite ce qu'une compromission peut dérober. Cependant, l'API ne rend pas une application sécurisée à elle seule. De mauvais choix d'algorithmes, la réutilisation de vecteurs d'initialisation, des clés codées en dur ou mal stockées et des sorties mal gérées la sapent tous. Point crucial, toute cryptographie effectuée dans le navigateur s'exécute encore dans un environnement qu'un attaquant peut contrôler : une faille de cross-site scripting peut appeler la même API, utiliser les clés disponibles et chiffrer ou signer pour le compte de l'attaquant.

Comment l'utiliser en toute sécurité

Choisissez des algorithmes et des paramètres actuels et bien compris, générez les clés et les IV avec getRandomValues, et n'expédiez jamais de clés secrètes dans le code client. Marquez les clés comme non extractibles chaque fois que le flux de travail le permet, et appuyez-vous sur les fonctions de dérivation de clés de l'API plutôt que d'inventer les vôtres. Comme la cryptographie côté navigateur ne protège les données que dans la mesure où l'on peut faire confiance au client, gardez la page environnante exempte de script injecté : appliquez une Content Security Policy stricte et nettoyez les entrées pour couper court aux XSS. La Web Crypto API est une primitive neutre de la plateforme web, si bien que cside n'intervient pas directement dans son fonctionnement ; la discipline défensive pertinente relève du développement sécurisé standard et du fait de tenir tout JavaScript tiers non fiable à l'écart de la page.

Définition

Devrais-je utiliser la Web Crypto API plutôt qu'une bibliothèque cryptographique JavaScript ?

En général oui. Les primitives natives sont plus rapides, sont maintenues par les éditeurs de navigateurs et évitent bon nombre des écueils d'implémentation de la cryptographie en pur JavaScript, notamment un aléa faible. Les bibliothèques gardent leur utilité pour les algorithmes que l'API ne propose pas, mais pour le hachage, le chiffrement et la signature standards, l'API intégrée est le choix par défaut le plus sûr.

Définition

La Web Crypto API rend-elle le chiffrement côté client totalement sécurisé ?

Non. Elle s'exécute dans le navigateur, un environnement que la machine de l'utilisateur et tout script injecté peuvent influencer. Elle renforce les primitives, mais une faille de cross-site scripting peut invoquer la même API et détourner les clés disponibles. Elle complète, sans les remplacer, le chiffrement du transport et les contrôles côté serveur.

Got more questions

Talk to a security expert

We answer client-side security questions every day. Bring yours.

Réserver une démonstration

Envie de passer tout ça en revue avec un ingénieur ?

Trente minutes, sur votre propre site. Pas de slides.

Nous vous montrerons :

Quels scripts tiers s'exécutent actuellement sur votre site
Où vous en êtes sur les exigences PCI DSS 6.4.3 et 11.6.1
Quelle part de votre trafic provient de bots et d'agents IA

Vous préférez simplement poser une question ?

Recherche de créneaux…

Humains uniquement. On le saurait.

Un problème pour réserver ? Ouvrir le calendrier dans un nouvel onglet

Quel problème cherchez-vous à résoudre ?

Dites-le-nous en une ligne et nous reviendrons vers vous avec quelque chose d'utile, pas un discours générique.

Nous aidons souvent sur :

Voir quels scripts tiers s'exécutent sur votre site
Les preuves pour PCI DSS 6.4.3 et 11.6.1
Les bots, les agents IA et le vol de comptes

Vous préférez réserver un créneau ? Choisir un créneau