Faille de sécurité DJI Romo : l’échec de l’isolation logique sur un bus MQTT multi-tenant
En février 2026, le robot aspirateur DJI Romo, incursion remarquée de la marque dans la domotique, a été le théâtre d’une vulnérabilité critique. Contrairement à une intrusion complexe, l’incident repose sur un défaut d’autorisation côté serveur (BOLA) dans l’architecture cloud. Environ 7 000 appareils dans 24 pays ont vu leurs données techniques et flux vidéo exposés.
Cette affaire, révélée par le développeur Sammy Azdoufal et documentée notamment par The Verge, souligne un paradoxe structurel : la sécurité des objets connectés dépend moins de leur firmware que de la rigueur des ACL (Access Control Lists) de leur infrastructure serveur.
Une découverte accidentelle par détournement de SDK
À l’origine, Sammy Azdoufal souhaitait simplement piloter son robot à l’aide d’une manette de PlayStation 5. En analysant les communications réseau entre l’appareil et l’infrastructure DJI Cloud API, il a identifié une rupture d’isolation des permissions.
Comme l’explique The Verge, l’utilisation de son propre token d’authentification, pourtant légitime, lui a permis d’interroger des ressources liées à des appareils tiers.
En quelques minutes, environ 7 000 robots actifs ont pu être identifiés. Les données accessibles comprenaient :
- Numéros de série (SN) et état de la batterie
- Adresse IP approximative et plans 2D des habitations
- Accès aux flux vidéo en direct, court-circuitant parfois la validation du code PIN
La présence d’un microphone embarqué a renforcé les inquiétudes en matière de vie privée. Cette intrusion démontre que si le « tuyau » (TLS) était chiffré, le contrôle de ce qui y circulait était défaillant.
Anatomie de la faille : le Broken Object Level Authorization (BOLA)
Le protocole utilisé par le DJI Romo est MQTT (Message Queuing Telemetry Transport), standard de l’IoT pour sa légèreté. Il convient toutefois de préciser : le protocole n’est pas vulnérable en lui-même. L’échec provient de son implémentation côté serveur.
Structure des topics et isolation logique
Dans l’architecture DJI, chaque appareil communique via des « topics » segmentés par le numéro de série (SN). Selon la documentation de la Cloud API, la structure type est la suivante :
thing/product/{device_sn}/osd thing/product/{device_sn}/state
L’erreur technique majeure réside dans la gestion des wildcards. Un client autorisé ne devrait avoir accès qu’aux topics correspondant à son propre {device_sn}. Or, la configuration des serveurs permettait l’abonnement à des flux au-delà du périmètre autorisé.
Authentification vs Autorisation
Le système validait correctement l’identité de l’utilisateur (Authentification), mais échouait à restreindre son périmètre d’action (Autorisation).
Ce cas d’école de BOLA sur bus de messages rappelle que la robustesse d’un système distribué ne vaut que par la finesse de ses ACL, un point que nous avons déjà analysé dans notre dossier sur les défis d’intégration du protocole MCP, où la couche protocolaire n’est pas en cause, mais bien son implémentation.
Flux vidéo et contournement du PIN : une sécurité de façade
L’un des points les plus critiques concerne l’accès aux caméras. Bien que l’application DJI propose une protection par code PIN pour visionner le flux en direct, le backend ne validait pas systématiquement cette preuve avant l’ouverture de la session WebRTC ou RTSP.
En exploitant les credentials MQTT, un utilisateur pouvait directement solliciter les services de streaming média du robot. Cette faille de conception illustre une problématique classique : une validation côté interface ne suffit pas si le backend ne l’exige pas.
DJI a reconnu un problème de validation des permissions côté serveur et a déployé des correctifs les 8 et 10 février 2026.
Analyse de la remédiation : un correctif exclusivement backend
Un élément technique confirme l’origine serveur de la faille : aucune mise à jour firmware du robot n’a été nécessaire.
La remédiation s’est faite côté infrastructure :
- Reconfiguration des brokers MQTT
- Durcissement de la Cloud API
- Mapping strict token → numéro de série
- Mise à jour des règles middleware
Ce type d’intervention est comparable aux mécanismes d’isolation que nous détaillons dans notre analyse sur la sécurisation des environnements agentiques, où la gouvernance des accès constitue la première ligne de défense.
Cloud centralisé vs Edge computing : un débat structurel
L’affaire DJI Romo relance une question centrale de sécurité IoT : pourquoi faire transiter des flux vidéo et des cartographies laser via un serveur tiers lorsque le traitement pourrait rester local ?
Dans l’approche Cloud centralisée :
- Les flux vidéo transitent par un broker distant
- Les plans 2D sont stockés dans l’infrastructure globale
- Une erreur d’ACL peut avoir un impact mondial
À l’inverse, une architecture Edge computing ou Local-first limite la surface d’attaque :
- Traitement local des images
- Tunnels chiffrés P2P
- Réduction du rôle du cloud à la signalisation
Ce modèle réduit considérablement le risque de fuite systémique en cas de défaut d’autorisation.
Vers une sécurité d’architecture, au-delà du firmware
L’incident du DJI Romo doit être lu comme un signal fort : la sécurité IoT ne dépend plus uniquement du chiffrement TLS ou du firmware embarqué.
Elle exige :
- Isolation logique granulaire
- Principe du moindre privilège
- Validation backend Zero Trust
- Segmentation réseau
Dans un monde multi-tenant où des milliers d’objets partagent une même infrastructure cloud, une seule erreur d’ACL peut exposer un parc entier d’appareils.
FAQ : Sécuriser son écosystème IoT domestique
Comment vérifier si mon DJI Romo est protégé ?
La correction ayant été appliquée côté serveur le 10 février 2026, aucune action manuelle n’est requise sur le robot. Assurez-vous toutefois que votre application DJI est à jour.
Pourquoi le chiffrement TLS n’a-t-il pas suffi ?
TLS protège le transport. Ici, l’utilisateur disposait d’un token valide mais le serveur ne vérifiait pas correctement l’autorisation liée à l’objet demandé.
Existe-t-il un mode « Local uniquement » ?
La majorité des fonctionnalités dépend de l’API Cloud. Pour renforcer votre sécurité :
- Créez un VLAN dédié aux objets IoT
- Utilisez un réseau Wi-Fi invité
- Désactivez l’UPnP si inutile
Pour ne rien rater, abonnez-vous à Cosmo Games sur Google News et suivez-nous sur X (ex Twitter) en particulier pour les bons plans en direct. Vos commentaires enrichissent nos articles, alors n'hésitez pas à réagir ! Un partage sur les réseaux nous aide énormément. Merci pour votre soutien !
