IndexedDB est une API de bas niveau destinée au stockage côté client de quantités importantes de données structurées. Bien que puissante, elle nécessite une réflexion approfondie en matière de sécurité, car les données stockées peuvent être vulnérables aux attaques XSS. Une purification adéquate des données, des contrôles d'accès et le chiffrement des données sensibles sont essentiels lors de l'utilisation d'IndexedDB dans les applications web.
IndexedDB est une base de données transactionnelle de bas niveau intégrée au navigateur pour stocker de grandes quantités de données structurées côté client. Contrairement au simple modèle clé-valeur en chaînes du Local Storage, elle contient des objets JavaScript structurés et des fichiers, prend en charge des index pour des recherches efficaces et regroupe les opérations en transactions. Son API est asynchrone et pilotée par événements ou par promesses, de sorte que les lectures et écritures volumineuses ne bloquent pas le thread principal. Les quotas de stockage sont bien plus élevés que ceux du Web Storage, souvent plusieurs centaines de mégaoctets voire davantage selon l'espace disque. Comme les autres stockages côté client, elle est cloisonnée par origine, et elle sous-tend les applications web orientées hors ligne, les progressive web apps et toute fonctionnalité nécessitant un jeu de données local interrogeable.
IndexedDB est soumise à la politique de même origine et n'est pas partagée entre origines, mais au sein d'une origine elle est entièrement lisible et modifiable par n'importe quel script en cours d'exécution, y compris du code injecté ou tiers. Elle n'offre aucun chiffrement intégré, si bien que tout ce qui y est stocké se retrouve en clair sur le disque de l'utilisateur et est exposé à une charge utile de cross-site scripting capable d'ouvrir la base et d'en lire chaque enregistrement. Comme elle est conçue pour contenir bien plus de données que le Local Storage, une brèche peut divulguer des volumes bien plus importants, y compris des données personnelles mises en cache ou des copies hors ligne d'enregistrements. Des données également relues depuis IndexedDB et affichées sans nettoyage constituent un chemin classique vers un XSS basé sur le DOM.
Ne stockez que ce dont l'application a réellement besoin hors ligne, et évitez de conserver des secrets ou des jetons bruts dans IndexedDB. Si des données sensibles doivent être mises en cache, chiffrez-les au niveau applicatif, idéalement avec des clés dérivées via la Web Crypto API et jamais conservées à côté des données. Traitez chaque valeur lue depuis la base comme une entrée non fiable : validez-la et encodez-la avant de l'insérer dans le DOM. Une Content Security Policy stricte limite les scripts autorisés à s'exécuter et à atteindre la base. Le rôle de cside se situe du côté des scripts tiers ; son méthode Script et son analyse de charge utile peuvent détecter et bloquer en temps réel un script externe qui se met à ouvrir et à exfiltrer le contenu d'IndexedDB.
Non, pas par défaut. IndexedDB stocke les données en clair sur le disque de l'utilisateur, et n'importe quel script de l'origine peut les lire. Si vous avez besoin de confidentialité, vous devez chiffrer les valeurs vous-même dans l'application, par exemple avec la Web Crypto API, avant de les écrire dans la base.
Bien davantage. Le Local Storage est généralement plafonné autour de 5 à 10 Mo par origine, tandis que les quotas d'IndexedDB atteignent couramment plusieurs centaines de mégaoctets ou un pourcentage du disque disponible, ce qui la rend adaptée aux jeux de données hors ligne. Cette capacité plus grande signifie aussi qu'une compromission peut exposer un volume de données bien plus important.
We answer client-side security questions every day. Bring yours.