Qu’est-ce qu’une injection NoSQL ? Comment fonctionne-t-elle et comment la prévenir

Qu’est-ce qu’une injection NoSQL ?

L’injection NoSQL est une vulnérabilité qui permet aux attaquants de manipuler les requêtes envoyées aux bases de données NoSQL. Ils insèrent des opérateurs malveillants, du code JavaScript ou une syntaxe spécialement conçue dans des entrées utilisateur non assainies. Officiellement classée sous CWE-943, « Neutralisation incorrecte des éléments spéciaux dans la logique des requêtes de données », dans la Common Weakness Enumeration (CWE), elle cible des bases de données comme MongoDB, Redis, Cassandra et Elasticsearch, qui utilisent des langages de requête flexibles, sans schéma fixe, plutôt que le SQL standard.

Une exploitation réussie va bien au-delà d’une seule requête malveillante. Un attaquant peut contourner entièrement l’authentification, extraire des données sensibles caractère par caractère, modifier des enregistrements, provoquer un déni de service ou exécuter du code arbitraire sur le serveur. Comme le WSTG de l’OWASP le souligne, « les conséquences potentielles sont plus importantes que celles d’une injection SQL classique », car les charges utiles d’injection NoSQL peuvent s’exécuter dans un langage procédural comme JavaScript, et pas seulement dans un langage de requête déclaratif.

Les bases de données NoSQL sont aujourd’hui utilisées partout, des systèmes de connexion et plateformes de chat aux catalogues e-commerce et consoles de gestion IoT. Leur adoption croissante, associée à l’idée fausse selon laquelle « pas de SQL signifie pas d’injection », fait de cette catégorie de vulnérabilités un risque persistant. C’est faux, et les attaquants en profitent. 

Avant d’examiner le fonctionnement de l’injection NoSQL en pratique, il faut comprendre sa place dans les frameworks standard de classification des vulnérabilités.

Classification OWASP

L’OWASP classe l’injection NoSQL dans la catégorie Injection, tant dans son Top 10 de 2021 que dans celui de 2025. Elle appartient à la même famille de risques que l’injection SQL, mais sa cause profonde relève d’une classification différente, ce qui influe sur les méthodes de test et de signalement.

La distinction essentielle tient à la correspondance avec les CWE. L’injection SQL classique relève de CWE-89 (neutralisation incorrecte des éléments spéciaux utilisés dans une commande SQL), tandis que l’injection NoSQL correspond à CWE-943 (neutralisation incorrecte des éléments spéciaux dans la logique des requêtes de données). CWE-943 couvre les langages de requête autres que SQL, notamment les opérateurs Binary JSON (BSON) de MongoDB, les commandes du protocole Redis et les requêtes REST de CouchDB.

Si votre programme de tests de sécurité ou vos rapports de conformité ne suivent que CWE-89, les injections NoSQL détectées risquent d’être mal classées ou de passer complètement inaperçues. Alignez vos outils et votre taxonomie sur CWE-943 pour éliminer cet angle mort. 

Une fois cette classification établie, il faut comprendre les mécanismes précis qu’utilisent les attaquants pour exploiter les interfaces de requête NoSQL.

Comment fonctionne l’injection NoSQL ?

L’injection NoSQL exploite l’écart entre les entrées utilisateur attendues par votre application et celles qu’elle reçoit réellement. Alors que l’injection SQL cible un langage de requête universel, l’injection NoSQL varie selon la base de données. MongoDB utilise des opérateurs de requête BSON/JSON, Redis utilise le protocole de communication Redis Serialization Protocol (RESP) et CouchDB expose une API HTTP REST. Chaque base de données présente une surface d'attaque, mais le principe reste le même : des données contrôlées par l'utilisateur entrent dans une requête sans validation adéquate et en modifient la logique.

Injection d'opérateurs : la technique la plus courante

Dans une application Node.js classique utilisant MongoDB, un endpoint de connexion pourrait construire une requête comme celle-ci :

Une requête légitime envoie {"username":"admin","password":"secret"}. Mais un attaquant peut soumettre :

L'opérateur $ne (différent de) indique à MongoDB de renvoyer tous les utilisateurs dont le nom d'utilisateur et le mot de passe sont différents de "invalid", ce qui correspond à tous les comptes valides. L'authentification est contournée en une seule requête, sans attaque par force brute.

Injection de JavaScript via $where

Lorsque des applications transmettent des données saisies par l'utilisateur à l'opérateur $where de MongoDB ou à des fonctions comme mapReduce, $accumulator ou $function, la base de données les évalue comme du JavaScript côté serveur. Un attaquant qui injecte une boucle infinie peut bloquer l'instance MongoDB et provoquer un déni de service. Au-delà de l'accès aux données, l'exécution de code JavaScript arbitraire peut entraîner une exécution de code à distance sur le serveur de base de données.

Extraction à l'aveugle

Lorsque l'application ne renvoie pas directement les résultats des requêtes, les attaquants utilisent des techniques fondées sur les réponses booléennes ou les temps de réponse pour extraire les données caractère par caractère. En soumettant des expressions régulières comme password[$regex]=^a et en observant si la réponse diffère de celle obtenue avec une condition nécessairement fausse, un attaquant peut reconstituer des mots de passe, des jetons et d'autres secrets sans jamais voir directement une fuite de données.

Injection de commandes Redis via CRLF

Dans RESP, les commandes sont séparées par des séquences retour chariot et saut de ligne (CRLF) (\r\n). Lorsqu'une application concatène des données saisies par l'utilisateur dans des commandes du protocole Redis sans les assainir, un attaquant peut injecter des séquences CRLF pour terminer la commande en cours et ajouter des commandes non autorisées sur la même connexion.

Redis stocke les données sous forme de paires clé-valeur. Des commandes injectées comme SET, GET et CONFIG peuvent lire des données sensibles, écraser des clés ou reconfigurer entièrement le serveur. Cette technique est souvent associée à une falsification de requêtes côté serveur (SSRF) : l'attaquant exploite une vulnérabilité SSRF pour atteindre une instance Redis interne non exposée à l'Internet public, puis injecte des commandes supplémentaires par ce canal.

Injection dans l'API HTTP de CouchDB

CouchDB expose une API REST/HTTP : toutes les opérations sur la base de données passent par des requêtes HTTP standard avec des données au format JSON. L'injection se produit lorsqu'une application transmet des données saisies par l'utilisateur sans les assainir dans les paramètres de requête, les définitions de vues ou les objets sélecteurs Mango de CouchDB.

Comme CouchDB utilise des vues MapReduce écrites en JavaScript, elle présente un risque d'exécution côté serveur similaire à celui de l'opérateur $where de MongoDB. Un attaquant capable d'influencer le JavaScript exécuté dans une vue MapReduce peut exécuter du code arbitraire sur le serveur de base de données. La fonction de réplication de CouchDB peut aussi être détournée au moyen de requêtes HTTP spécialement conçues pour déclencher une attaque SSRF contre des services internes.

Chaque base de données NoSQL présente une surface d'attaque distincte, qu'il s'agisse des opérateurs BSON de MongoDB, de l'injection CRLF dans le protocole Redis ou de l'API REST de CouchDB. Vos défenses contre l'injection NoSQL doivent être adaptées à l'interface de requête propre à chaque base de données.

Ces mécanismes fonctionnent quels que soient les types de contenu, les couches de transport et les frameworks. Leurs causes profondes se répètent, et c'est dans cette répétition que les défenseurs prennent l'avantage.

Causes de l'injection NoSQL

L'injection NoSQL ne résulte pas d'une seule erreur de programmation. Elle naît d'une combinaison d'hypothèses architecturales, de comportements des frameworks et de couches de validation manquantes, dont les effets se cumulent à l'exécution.

Validation insuffisante des entrées et absence de contrôle des types

Votre application peut supposer qu'un champ comme password arrivera toujours sous forme de chaîne de caractères, mais les corps de requêtes HTTP, les charges utiles JSON et les paramètres encodés dans les URL peuvent contenir des objets et des tableaux. Quand le body-parser d'Express.js reçoit password[$ne]=x, il le désérialise automatiquement en { password: { $ne: "x" } }, un objet contenant un opérateur MongoDB, avant même que le code de l'application ne le traite.

Construction dynamique des requêtes

Si vous construisez des requêtes par concaténation ou interpolation de chaînes plutôt qu'avec des objets de requête structurés, les attaquants peuvent rompre la syntaxe de la requête et injecter une nouvelle logique. Le forum MongoDB le confirme : « Dans la plupart des cas, les injections externes résultent d'une concaténation non sécurisée de chaînes lors de la création des requêtes. »

JavaScript côté serveur laissé activé

MongoDB prend en charge l'exécution de JavaScript via $where, mapReduce, $accumulator et $function. La checklist MongoDB recommande explicitement de désactiver les scripts côté serveur avec --noscripting lorsque ces opérations ne sont pas utilisées. Les laisser activés crée une surface d'attaque propice à l'exécution de code arbitraire.

Conversion des types au niveau des frameworks

PHP convertit automatiquement username[$ne]=toto en ['username' => ['$ne' => 'toto']]. Le body-parser d'Express.js fait de même avec les données de formulaire encodées dans les URL : il désérialise password[$ne]=x en { password: { $ne: "x" } }, un objet contenant un opérateur MongoDB, avant même que la requête n'atteigne le code de l'application. Ces comportements des frameworks transforment des paramètres HTTP d'apparence anodine en opérateurs de base de données, sans intervention délibérée du développeur.

Vulnérabilités de la couche ORM

Même si MongoDB est renforcé, la bibliothèque de mapping objet-relationnel (ORM) de votre application peut créer des surfaces d'injection. CVE-2024-53900 a démontré que l'opérateur $where de Mongoose pouvait être exploité à l'aide d'entrées contrôlées par l'utilisateur, et CVE-2025-23061, qui révèle un correctif incomplet pour la première faille, a montré que $where pouvait encore être contourné par imbrication sous $or dans la fonctionnalité populate().match de Mongoose, contournant entièrement les protections au niveau du serveur.

Validation du protocole réseau désactivée

MongoDB valide les documents entrants au niveau du protocole réseau grâce au paramètre net.wireObjectCheck. Le désactiver supprime une protection structurelle qui empêche les données BSON malformées d'atteindre le moteur de requêtes.

Ces causes créent une surface d'attaque qui s'étend de l'analyse des requêtes HTTP à l'exécution des requêtes en base de données, avec des conséquences directes pour l'entreprise.

Impact et risques

L'injection NoSQL touche les trois dimensions de la triade confidentialité, intégrité et disponibilité (CIA), souvent simultanément.

• Confidentialité : Les attaquants peuvent lire des documents arbitraires, énumérer les noms des champs et extraire des identifiants caractère par caractère grâce à des techniques d'injection à l'aveugle. Dans le cas de CVE-2021-22911, des chercheurs ont divulgué des hachages de mots de passe administrateur et des jetons de réinitialisation de mot de passe provenant d'instances Rocket.Chat.
• Intégrité : L'injection d'opérateurs et l'exploitation abusive des requêtes brutes permettent aux attaquants de modifier, remplacer ou supprimer des documents. Des requêtes ajoutées à une requête existante peuvent insérer de nouveaux enregistrements ou écraser les valeurs de champs existants.
• Disponibilité : Une charge utile $where exécutant une boucle active peut saturer une instance MongoDB et rendre la base de données indisponible, sans inonder le réseau.
• Le contournement de l'authentification figure parmi les conséquences les plus souvent documentées. L'injection NoSQL offre ainsi un accès initial direct aux applications exposées à Internet.
• Les risques liés à la chaîne d'approvisionnement et aux systèmes en aval amplifient les conséquences d'une injection NoSQL dans les produits de plateforme. Lorsqu'une vulnérabilité compromet une plateforme comme Rocket. Chat ou Parse Server, ses conséquences touchent aussi les clients et les utilisateurs en aval. Une seule faille d'injection dans un produit backend-as-a-service peut exposer de nombreuses applications construites sur cette plateforme et compromettre ainsi plusieurs environnements.
• Les conséquences réglementaires et de conformité découlent directement des atteintes à la confidentialité. Lorsqu'une injection NoSQL entraîne l'exfiltration de données personnelles, d'identifiants ou de communications clients, les organisations doivent respecter les obligations de notification des violations prévues par des réglementations comme le RGPD, HIPAA, PCI DSS et les lois sur la protection de la vie privée en vigueur dans les différents États. La technique d'extraction caractère par caractère utilisée dans les attaques par injection à l'aveugle peut exfiltrer discrètement des données sensibles sur de longues périodes. Cette fuite progressive passe facilement inaperçue. Une détection précoce est donc essentielle.

• L'exécution de code à distance est confirmée par l'évaluation de JavaScript côté serveur. L'OWASP WSTG indique que "JavaScript étant un langage complet, cette fonctionnalité permet à un attaquant non seulement de manipuler les données, mais aussi d'exécuter du code arbitraire". Un article du Symposium international sur la criminalistique numérique et la sécurité 2025 (ISDFS) décrit sans détour ce risque : "JavaScript est si puissant qu'exposer une telle vulnérabilité revient à remettre une mitrailleuse à un grand criminel."

Les défenseurs qui connaissent les méthodes des attaquants peuvent les contrer à chaque étape. Voici comment se déroule une attaque.

Comment les attaquants exploitent l'injection NoSQL

Les attaquants suivent une méthode structurée pour trouver et exploiter les failles d'injection NoSQL, de la reconnaissance à l'exfiltration de données ou à l'exécution de code.

Phase 1 : découverte des vecteurs d'entrée

L'attaquant repère les paramètres transmis à un backend NoSQL : paramètres d'URL, corps des requêtes POST au format JSON, en-têtes HTTP et messages WebSocket. Il soumet des caractères de test (' " \ ; { }) et observe les messages d’erreur ou les changements de comportement révélant une interaction avec la base de données.

Phase 2 : confirmation de l’injection d’opérateurs

Sur un endpoint de connexion, l’attaquant remplace une chaîne d’identifiants normale par un opérateur $ne :

Si l’application accepte la connexion sous l’identité d’un autre utilisateur, l’injection d’opérateurs est confirmée. L’attaquant peut aussi tester l’opérateur $gt (supérieur à) pour confirmer la faille autrement :

L’opérateur $gt avec une chaîne vide correspond à toute valeur de mot de passe non vide. Si la connexion au compte administrateur réussit sans mot de passe valide, l’injection d’opérateurs est confirmée une seconde fois.

Phase 3 : contournement de l’authentification

L’attaquant passe à l’étape suivante en injectant des opérateurs dans les deux champs :

Cette attaque cible précisément les comptes à privilèges et renvoie le premier utilisateur dont le nom figure dans la liste et dont le mot de passe est une chaîne non vide.

Phase 4 : exfiltration de données

Grâce à l’injection $where en JavaScript, l’attaquant vérifie l’existence de champs :

Si la réponse correspond à un modèle reconnu comme valide, le champ resetToken existe. L’attaquant extrait ensuite sa valeur caractère par caractère au moyen d’une injection aveugle basée sur des réponses booléennes. Il soumet pour cela un motif d’expression régulière tel que {"resetToken":{"$regex":"^A"}} et observe la réponse HTTP. Un code d’état de réussite ou un corps de réponse précis indique que le caractère correspond. Une réponse différente indique le contraire. L’attaquant teste ainsi chaque position, en parcourant tous les caractères possibles à chaque étape. Comme le montre CVE-2024-37405, cette extraction peut s’appuyer sur des requêtes différentielles répétées. L’injection aveugle constitue donc une attaque réalisable, et non un risque purement théorique.

Phase 5 : élévation des privilèges et mouvement latéral

À l’aide des identifiants ou des jetons de réinitialisation extraits, l’attaquant obtient un accès administrateur. Il peut ensuite atteindre les systèmes backend et accéder à d’autres collections par injection dans un pipeline d’agrégation avec $lookup ou $unionWith (désignée par PortSwigger comme l’une des principales techniques de piratage web), ou établir une persistance en exécutant du code côté serveur. L’injection dans un pipeline d’agrégation avec $lookup a un impact majeur : elle peut lire des collections auxquelles la requête de l’application n’était pas censée accéder. Elle contourne ainsi les limites d’accès entre collections et expose les données de toute la base.

Changement de type de contenu

Les attaquants alternent fréquemment entre application/x-www-form-urlencoded et application/json pour trouver des points d’injection présents dans un seul type de contenu. Cette technique est particulièrement efficace contre les API REST qui acceptent plusieurs formats.

Ces techniques d’attaque s’appliquent partout où une base de données NoSQL accepte des données saisies par les utilisateurs. Certaines applications sont beaucoup plus exposées que d’autres.

Qui est concerné ?

L’injection NoSQL touche toute application qui transmet des données contrôlées par un utilisateur à une base de données NoSQL sans vérification adéquate des types. D’après les CVE confirmées, les catégories d’applications les plus exposées sont les suivantes :

• Systèmes d’authentification : Les endpoints de connexion constituent la surface d’attaque de référence documentée par toutes les grandes sources.
• Plateformes de collaboration en équipe : Rocket.Chat est concerné par plusieurs CVE d’injection NoSQL sur plusieurs années, dont une vulnérabilité exploitable avant authentification (CVE-2021-22911).
• Applications Node.js/Express utilisant Mongoose: Mongoose, un outil de mappage objet-document (ODM), introduit des surfaces d'injection au niveau de la couche ORM, indépendamment des contrôles propres à MongoDB.
• Backends de plateforme en tant que service: Parse Server (CVE-2022-24815, CVE-2026-30941) et Steedos Platform (CVE-2020-35666) illustrent l'exposition des produits backend en tant que service.
• IoT et gestion des réseaux: l'application UniFi Network d'Ubiquiti a fait l'objet d'une CVE d'injection NoSQL confirmée par le fournisseur, permettant une élévation de privilèges.
• Plateformes de commerce électronique: AquilaCMS a reçu une évaluation CRITICAL pour une injection NoSQL dans sa fonction de réinitialisation des mots de passe (CVE-2024-48573).
• API GraphQL: Les arguments de filtre GraphQL non assainis, transmis directement aux requêtes MongoDB, créent une surface d'injection souvent négligée.

MongoDB est largement utilisé, tout comme Node.js/Express pour le développement backend. Leur association crée une vaste surface d'attaque. NIST IR 8504 reconnaît officiellement l'injection NoSQL comme une catégorie de risque pour les systèmes du gouvernement américain. Ce risque concerne donc aussi les entreprises, et pas seulement les startups ou les environnements SaaS.

Les API GraphQL constituent un vecteur de plus en plus courant, car les arguments de filtre sont souvent transmis directement aux requêtes MongoDB sans liste d'autorisation explicite. Or, ce schéma est mal couvert par les règles traditionnelles traditionnelles des pare-feu applicatifs web (WAF) axées sur les charges utiles de type SQL.

Le point commun n'est pas le secteur d'activité, mais la pile technologique. Si votre application utilise MongoDB, Redis, CouchDB ou Elasticsearch avec des données saisies par les utilisateurs, elle est une cible potentielle. C'est particulièrement vrai si elle repose sur des frameworks JavaScript qui effectuent une conversion automatique des types. Les incidents confirmés suivants montrent à quoi ressemble une exploitation en pratique.

Exemples concrets

Des CVE confirmées et des chaînes d'exploitation publiées montrent comment l'injection NoSQL se manifeste dans les systèmes de production, des plateformes de collaboration et de commerce électronique aux produits backend en tant que service et aux infrastructures réseau.

Rocket.Chat: prise de contrôle d'un compte administrateur sans authentification (CVE-2021-22911)

Les recherches de SonarSource ont montré que la méthode getPasswordPolicy() de Rocket.Chat pouvait être appelée sans authentification. En injectant l'opérateur $regex de MongoDB dans le paramètre du jeton de réinitialisation du mot de passe, un attaquant pouvait extraire le jeton caractère par caractère en envoyant {"$regex":"^A"} et en observant les différences entre les réponses.

Le rapport confirmé de HackerOne a décrit la chaîne d'attaque: divulgation des noms d'utilisateur des administrateurs, des adresses e-mail, des empreintes de mots de passe et des jetons de réinitialisation, jusqu'à la prise de contrôle complète d'un compte administrateur.

@feathersjs/mongodb: injection d'objets via WebSocket (CVE-2026-29793)

Les clients Socket.IO pouvaient envoyer des objets JavaScript arbitraires comme argument id à n'importe quelle méthode de service Feathers. La couche de transport ne vérifiait pas les types. L'envoi de {$ne: null} comme argument id correspondait à tous les documents d'une collection. La vulnérabilité est référencée sous CVE-2026-29793.

Ubiquiti UniFi: élévation de privilèges après authentification (CVE-2026-22557)

Ubiquiti a confirmé dans son propre avis une vulnérabilité d'injection NoSQL dans l'application UniFi Network, exploitable après authentification et permettant une élévation de privilèges. Tout utilisateur authentifié pouvait exploiter cette faille pour obtenir des droits élevés et passer d'un compte à faibles privilèges au contrôle administratif total de l'infrastructure réseau.

Rocket.Chat Livechat: injection en chaîne (CVE-2024-37405)

Deux points d’injection NoSQL distincts ont été enchaînés : l’extraction d’un jeton visiteur par injection aveugle via $regex, suivie d’une seconde injection dans le paramètre rid pour extraire tous les messages Livechat. Cette attaque avant authentification a exposé les données de communication avec les clients.

AquilaCMS : injection critique dans la réinitialisation des mots de passe (CVE-2024-48573)

AquilaCMS, une plateforme de commerce électronique open source, a reçu une note CRITIQUE (9.8) pour une vulnérabilité d’injection NoSQL dans sa fonction de réinitialisation des mots de passe. Un attaquant non authentifié pouvait manipuler le processus de réinitialisation en injectant des opérateurs MongoDB dans le paramètre du jeton de réinitialisation, contournant ainsi entièrement la validation prévue. Comme AquilaCMS fait fonctionner des boutiques en ligne, une exploitation réussie mettait en péril les données des comptes clients, les informations de paiement et les historiques de commandes. La vulnérabilité ne nécessitait aucune authentification et pouvait être exploitée à distance au moyen d’une requête HTTP standard, par tout attaquant ayant accès à la boutique via le réseau.

Parse Server : vulnérabilités d’injection récurrentes (CVE-2022-24815, CVE-2026-30941)

Parse Server, une plateforme backend-as-a-service open source largement utilisée, a connu des vulnérabilités d’injection NoSQL récurrentes au fil des ans. CVE-2022-24815 associait une pollution de prototype à une injection NoSQL. Cette faille montre comment des vulnérabilités de la couche JavaScript et une injection dans la base de données peuvent se combiner pour ouvrir des voies d’exploitation qu’aucune des deux ne permettrait seule. Des années plus tard, CVE-2026-30941 a révélé que la plateforme présentait encore des points d’injection où les valeurs des jetons étaient transmises aux requêtes de base de données sans validation de leur type. Les produits backend-as-a-service sont des cibles de grande valeur, car une seule vulnérabilité touche toutes les applications développées sur la plateforme. Si Parse Server est compromis, les applications mobiles, les applications web et les backends IoT qui en dépendent peuvent être exposés à la même faille.

Ces incidents couvrent plusieurs années et différentes piles technologiques. L’injection NoSQL refait régulièrement surface dans les systèmes de production. La chronologie montre depuis combien de temps ce phénomène persiste.

Chronologie de l’injection NoSQL

La série de CVE de 2026 témoigne de l’intérêt croissant des chercheurs pour les piles Node.js/MongoDB. Elle suggère que l’injection NoSQL attire de nouveau l’attention, loin de disparaître. Cette tendance fait de la détection une priorité. Bonne nouvelle : les signaux sont bien connus.

Comment détecter l’injection NoSQL

La détection des injections NoSQL exige de combiner l’analyse statique du code, les tests dynamiques sur des endpoints actifs et la surveillance des comportements à l’exécution pour repérer les exploitations qui échappent à vos autres contrôles.

Analyse statique et revue de code

Examinez votre base de code pour repérer les schémas à haut risque. Signalez tout appel Mongoose .find(), .findOne(), ou un appel à .populate() qui transmet directement req.body, req.query ou req.params sans vérification des types. Recherchez toute utilisation de $where avec des données contrôlées par l’utilisateur, tout pipeline d’agrégation intégrant des objets de filtrage contrôlés par l’utilisateur et tout endpoint acceptant des objets de requête JSON bruts fournis par les clients. Signalez également toute utilisation de eval(), Function(), ou de littéraux de gabarit qui concatènent des données utilisateur dans des chaînes de requête. Examinez particulièrement les pipelines d’agrégation utilisant $lookup ou $unionWith avec des noms de collections ou des étapes de pipeline contrôlés par l’utilisateur : ils peuvent franchir les limites d’accès définies au niveau des collections.

Tests dynamiques

Suivez la méthodologie OWASP WSTG-INPV-05.6 :

1. Soumettez la chaîne de fuzzing '"\{ ;$Foo} $Foo \xYZ` pour repérer les points d’injection syntaxique.
2. Soumettez les caractères spéciaux ' " \ ; { } pour repérer les points d’injection d’opérateurs.
3. Utilisez la pollution des paramètres HTTP pour injecter un paramètre $where et observez les réponses d’erreur de MongoDB.
4. Comparez les réponses à des conditions connues comme vraies et comme fausses pour déceler les injections aveugles.

Testez également les canaux WebSocket. CVE-2026-29793 a montré que les clients Socket.IO pouvaient transmettre des objets JavaScript arbitraires comme arguments de méthodes de service, contournant ainsi toute inspection au niveau HTTP. De nombreux scanners se concentrent uniquement sur les endpoints HTTP et ignorent totalement les surfaces d’injection WebSocket. Des tests WebSocket manuels ou spécialisés comblent cette faille dans les applications reposant sur des frameworks de communication en temps réel.

Surveillance comportementale à l’exécution

Surveillez votre infrastructure pour repérer les indicateurs comportementaux d’une exploitation réussie :

• Processus de services de base de données (mongod, redis-server) lançant des processus enfants ou des shells inattendus
• Requêtes inhabituelles contenant la syntaxe d’opérateurs MongoDB ($where, $regex, $ne, $gt) dans les journaux applicatifs
• Pics d'utilisation du CPU sur les serveurs MongoDB sans charge correspondante de requêtes légitimes
• Des endpoints de réinitialisation de mot de passe reçoivent des objets plutôt que des chaînes dans les champs de jeton
• Écarts de temps de réponse sur les endpoints accessibles publiquement suggérant une injection aveugle fondée sur les temps de réponse

Outils de test d'intrusion

Des outils spécialisés vous aident à rechercher les injections NoSQL lors de vos évaluations :

• NoSQLMap: Outil open source conçu spécifiquement pour tester et exploiter les injections NoSQL
• nosqli: Outil en ligne de commande pour détecter automatiquement les injections NoSQL
• Burp Suite: Tests manuels avec les modules Repeater et Intruder, complétés par des extensions pour tester automatiquement les charges utiles NoSQL
• OWASP ZAP: Règles d'analyse active applicables aux endpoints NoSQL

Savoir où chercher représente la moitié du défi. L'autre moitié consiste à mettre en place des défenses qui empêchent toute exploitation dès le départ.

Comment prévenir les injections NoSQL

Pour bloquer les injections NoSQL, imposez des types stricts à toutes les données saisies par les utilisateurs avant qu'elles n'atteignent la couche de base de données. Les défenses ci-dessous répondent à chaque cause fondamentale identifiée plus haut, de la conversion des types au niveau du framework au contournement de la couche ORM.

Vérifiez les types avant de construire les requêtes

Rejetez tout champ dont la valeur n'est pas scalaire (chaîne, nombre ou booléen) avant qu'il n'atteigne votre ORM ou votre pilote de base de données. La conversion explicite des types est la défense la plus efficace :

Supprimez ou rejetez les clés d'opérateurs MongoDB

Vérifiez toutes les clés de req.body, req.query, et req.params pour détecter $ comme préfixe et rejetez ces clés avant qu'elles n'atteignent la couche de base de données. Utilisez key.startsWith('$') pour cette vérification plutôt qu'une expression régulière, dont les contournements connus sont documentés dans CVE-2021-22910.

Désactivez JavaScript côté serveur

Utilisez --noscripting ou set security.javascriptEnabled: false dans votre configuration MongoDB. Vous éliminez ainsi entièrement la surface d'attaque liée à $where. Privilégiez $expr et les générateurs de requêtes typées pour la logique conditionnelle.

Utilisez des frameworks de validation des schémas

Validez le type des données dès le début du traitement des requêtes avec des bibliothèques comme Joi, Ajv ou Zod. Elles rejettent les tableaux ou les objets lorsqu'une valeur scalaire est attendue, bloquant l'injection d'opérateurs avant qu'elle n'atteigne la base de données.

Fixez les versions de Mongoose et des ORM, surveillez les avis de sécurité

Les vulnérabilités de la couche ORM peuvent contourner entièrement les contrôles de l'application et de la base de données. CVE-2024-53900 et CVE-2025-23061 ont montré que la fonctionnalité populate().match de Mongoose pouvait être exploitée même lorsque JavaScript était désactivé côté serveur MongoDB. CVE-2025-23061 résultait d'un correctif incomplet de CVE-2024-53900, ce qui montre que les correctifs peuvent être insuffisants et nécessitent une vérification indépendante.

Abonnez-vous aux avis de sécurité de Mongoose et des autres bibliothèques ODM/ORM, fixez explicitement les versions des dépendances et vérifiez que chaque correctif de sécurité résout entièrement la vulnérabilité documentée avant de clôturer le ticket de remédiation.

N'acceptez jamais de requêtes JSON brutes provenant des clients

La fiche pratique OWASP l'indique explicitement : « N'acceptez pas de requêtes JSON brutes provenant des clients. » Une charge utile comme { "$where": "this.balance > 0" } envoyée par un client entraîne une exécution de code à distance ou une saturation du processeur.

Configurez la base de données selon le principe du moindre privilège

Utilisez des comptes de base de données dédiés à l'application, dotés des seules autorisations nécessaires. Ne vous connectez jamais avec des identifiants root ou administrateur. N'exposez pas les ports de la base de données ni les consoles d'administration à l'Internet public.

Gardez Wire Object Check activé

Le paramètre net.wireObjectCheck de MongoDB valide tous les documents au niveau du protocole réseau. Il est activé par défaut. Ne le désactivez jamais.

Sécurisez les filtres GraphQL

Convertissez les arguments des filtres GraphQL à l'aide d'une liste d'autorisation explicite. N'intégrez jamais directement des objets non fiables dans les filtres de requête MongoDB ou Mongoose.

Des contrôles applicatifs solides réduisent la surface d'attaque. Ils ne peuvent pas la supprimer entièrement. Une détection et une réponse à plusieurs niveaux couvrent ce qui leur échappe.

Outils de détection et de prévention

Une défense à plusieurs niveaux contre l'injection NoSQL associe contrôles applicatifs, outils de test et surveillance à l'exécution.

• Les défenses applicatives comprennent des bibliothèques de validation des entrées (Joi, Ajv, Zod), des protections au niveau des ORM (validation des schémas Mongoose, conversion explicite des types) et les contrôles de sécurité intégrés de MongoDB (--noscripting, wireObjectCheck, accès basé sur les rôles).
• Les outils de test comme NoSQLMap, nosqli, Burp Suite et OWASP ZAP recherchent les injections NoSQL pendant le développement et les cycles de tests d'intrusion.
• Les WAF constituent une couche de défense périmétrique capable de bloquer les schémas d'injection connus. Toutefois, les WAF reposent sur des règles fondées sur des signatures et ne peuvent pas bloquer les nouvelles charges utiles, les opérateurs masqués ni les injections via les canaux WebSocket.
• La surveillance comportementale à l'exécution comble les failles laissées par les WAF. De nouvelles charges utiles, des vulnérabilités de la couche ORM comme celle de populate().match dans Mongoose ou des canaux WebSocket non inspectés par les WAF peuvent contourner les contrôles applicatifs. La surveillance à l'exécution observe les conséquences d'une injection réussie : lancement de shells inattendus par les processus de base de données, schémas d'exécution JavaScript anormaux ou volumes de requêtes inhabituels, quel que soit le mode de transmission de la charge utile. Lorsqu'une charge utile échappe à l'inspection fondée sur les signatures et atteint la base de données, le comportement anormal qui en résulte devient l'indicateur de compromission le plus fiable.

Comment SentinelOne peut-il intervenir ?

L'inspection des charges utiles relève du WAF. SentinelOne surveille ce qui se passe ensuite. La plateforme détecte et bloque les conséquences comportementales d'une injection NoSQL réussie : les anomalies de processus, les mouvements latéraux et les activités post-exploitation qui échappent aux contrôles applicatifs.

La plateforme de SentinelOne, Singularity™ Platform, comprend Singularity AI SIEM, qui corrèle les données de télémétrie des endpoints, des charges de travail cloud, des systèmes de gestion des identités et des sources tierces dans un seul lac de données. Lors des évaluations MITRE ATT&CK 2024, la Singularity Platform a atteint un taux de détection de 100 % sans aucun délai, tout en générant 88 % d’alertes en moins que la médiane. Moins de bruit signifie que votre équipe peut se concentrer sur les menaces confirmées. Lorsqu’une attaque par injection NoSQL se propage d’une application web à un serveur de base de données, puis au vol d’identifiants, AI SIEM relie ces événements entre les différentes surfaces sans corrélation manuelle.

Au sein de Singularity Endpoint, Storyline relie en permanence les événements de création de processus, les connexions réseau, les modifications de fichiers et l'utilisation des identifiants sur chaque endpoint protégé. Ces événements forment des chaînes cohérentes qui retracent leur origine. Lors d'une attaque fondée sur $where pour exécuter du JavaScript côté serveur, Storyline relie automatiquement le processus du serveur web qui reçoit la requête malveillante, le service de base de données au comportement anormal, le processus d'interpréteur lancé et tout shell enfant. Tous sont associés à un identifiant Storyline unique. Les règles personnalisées de Storyline Active Response (STAR) se déclenchent lorsque des processus de base de données comme mongod ou redis-server lancent des processus enfants inattendus, un indicateur comportemental fiable d'une injection de commandes réussie.

Purple AI™ accélère les investigations grâce aux requêtes en langage naturel. Selon IDC, les clients de Purple AI identifient les menaces 63 % plus vite et réduisent de 55 % le délai moyen de remédiation (MTTR). Vous pouvez demander "montre-moi tous les processus lancés par mongod au cours des dernières 24 heures" ou faire directement référence à des techniques MITRE ATT&CK comme T1190 (Exploit Public-Facing Application) et T1059 (Command and Scripting Interpreter). La fonctionnalité Auto Investigation de Purple AI rassemble de manière autonome des preuves issues de l'ensemble de votre environnement, synthétise les données sur les menaces et reconstitue la chronologie complète des attaques. Des investigations qui prenaient des heures ne prennent plus que quelques minutes.

Cloud Workload Security protège les bases de données NoSQL hébergées dans le cloud pendant leur exécution. Cette capacité surveille le comportement des workloads en temps réel et utilise Verified Exploit Paths pour faire ressortir des résultats étayés par des preuves. Vous voyez quand une injection NoSQL visant une instance MongoDB ou Redis hébergée dans le cloud entraîne une activité post-exploitation.

Pour les organisations qui exploitent des bases de données NoSQL à grande échelle, ces capacités comblent la faille entre la prévention au niveau des applications et la visibilité sur les activités post-exploitation. 

Demandez une démo SentinelOne pour voir ces capacités en action.

Vulnérabilités connexes

L'injection NoSQL partage ses causes profondes et ses modes d'attaque avec plusieurs catégories de vulnérabilités connexes :

• Injection SQL (CWE-89) : C'est son équivalent pour les bases de données relationnelles. Toutes deux exploitent une neutralisation incorrecte des entrées utilisateur dans les requêtes de base de données. Mais la capacité de l'injection NoSQL à exécuter un langage procédural étend son impact au-delà de la manipulation des données, jusqu'à l'exécution de code arbitraire.
• Falsification de requête côté serveur (SSRF) : L'injection CRLF dans Redis est souvent combinée à la SSRF. Un attaquant utilise la SSRF pour atteindre une instance Redis interne, puis injecte des commandes supplémentaires au moyen de séquences CRLF.
• Injection de commandes (CWE-78) : Quand l'injection NoSQL aboutit à l'exécution de JavaScript côté serveur au moyen de $where, la capacité obtenue ressemble étroitement à l'injection de commandes du système d'exploitation.
• Pollution de prototype : CVE-2022-24815 dans Parse Server associait pollution de prototype et injection NoSQL. Ce cas montre comment les vulnérabilités de la couche JavaScript aggravent les effets d'une injection dans la base de données.
• Script intersites (XSS) : Le XSS et l'injection NoSQL résultent tous deux d'une validation insuffisante des entrées. Les organisations vulnérables à l'un présentent souvent des faiblesses systémiques de validation qui les exposent à l'autre.

Comprendre ces liens vous aide à prioriser les tests et les mesures correctives pour les catégories de vulnérabilités connexes, plutôt que de traiter chacune séparément. Le tableau suivant répertorie les CVE confirmées liées à l'injection NoSQL.