Tests de sécurité HarmonyOS Next : outils et risques

Introduction

Avec près d'un milliard d'appareils sous HarmonyOS, les tests de sécurité sont devenus essentiels pour de nombreuses équipes qui développent des applications mobiles. Cependant, avec l'arrivée de HarmonyOS Next, un changement majeur est intervenu : la compatibilité Android n'est plus incluse. C'est important, car le système ne repose plus sur le runtime ni sur le framework Android pour lesquels la plupart des outils de sécurité sont conçus. Résultat : de nombreux outils de test Android cessent de fonctionner ou produisent des résultats incomplets. C'est pourquoi les tests de sécurité exigent désormais des approches conçues spécifiquement pour HarmonyOS, plutôt que de supposer un comportement basé sur Android.

Qu'est-ce que HarmonyOS Next

HarmonyOS Next (HarmonyOS 5.0) est l'une des dernières versions de Huawei, lancée en 2024, qui s'éloigne d'Android et devient un système d'exploitation entièrement indépendant. Les versions précédentes de HarmonyOS incluaient encore des composants Android, ce qui permettait d'exécuter des applications Android. HarmonyOS Next supprime toutefois complètement cette compatibilité. Il est entièrement bâti sur le système propre de Huawei, y compris son propre noyau (HongMeng). Il ne prend donc plus en charge les applications Android et n'exécute que les applications développées spécifiquement pour HarmonyOS (.app).

Pourquoi les tests de sécurité de HarmonyOS Next diffèrent de ceux d'Android

HarmonyOS partage des similitudes de surface avec Android, notamment une boutique d'applications (AppGallery), un système de permissions et la prise en charge du code natif. Son architecture interne est cependant totalement différente, ce qui influe directement sur la manière de mener les tests de sécurité.

Runtime des applications et ArkTS

Les applications HarmonyOS sont développées avec ArkTS (Ark TypeScript), un langage basé sur TypeScript conçu par Huawei pour créer des applications via le framework ArkUI. Il adopte une approche d'interface déclarative : les développeurs décrivent à quoi l'interface doit ressembler au lieu de contrôler manuellement chaque étape du rendu.

Au lieu d'être compilées en bytecode DEX d'Android, les applications ArkTS sont compilées en bytecode Panda (.abc). Cela rend tous les outils de sécurité Android incompatibles. Les outils d'analyse statique conçus pour Java/Kotlin, ainsi que les workflows de rétro-ingénierie prévus pour les fichiers DEX, ne s'appliquent pas directement ici.

Communication inter-processus et DSoftBus

Au lieu du système Binder d'Android, HarmonyOS utilise DSoftBus, une couche de communication conçue pour l'interaction entre appareils.

Cela fait passer le modèle d'applications qui communiquent au sein d'un seul téléphone à celui d'applications et de services qui interagissent entre plusieurs appareils. Les tests de sécurité ne portent donc plus seulement sur un appareil isolé, mais aussi sur la circulation des données entre appareils connectés.

Le changement le plus important de HarmonyOS est qu'il est conçu autour de plusieurs appareils qui fonctionnent ensemble.

Contrairement à Android, où un téléphone, une tablette ou une montre sont des environnements distincts, HarmonyOS permet aux applications et aux services de s'exécuter sur des téléphones, tablettes, montres, téléviseurs et autres appareils connectés.

Cela signifie que la surface d'attaque ne se limite plus à un seul appareil. Il faut aussi tenir compte de ce qui se passe lorsque des appareils se font confiance et partagent des données.

Les permissions de HarmonyOS peuvent aussi s'étendre à plusieurs appareils, et pas seulement rester sur un seul.

Une application ne demande donc pas seulement l'accès à des éléments du téléphone lui-même, mais parfois à des capacités qui impliquent d'autres appareils connectés de l'écosystème. Le comportement des permissions devient ainsi plus difficile à analyser et plus facile à détourner s'il n'est pas vérifié avec soin.

Outils de test de sécurité HarmonyOS NEXT

Les outils de test de sécurité pour HarmonyOS en sont encore à un stade précoce de développement, comparés à l'écosystème Android arrivé à maturité. Voici quelques-uns des outils les plus importants disponibles aujourd'hui :

Catégorie	Outil / ressource	Objectif principal	Capacités clés	Limites
Outils officiels de Huawei	AppGallery Cloud Testing	Contrôles de référence automatisés	Vérifie les problèmes de configuration connus et les motifs de vulnérabilité.	Ne remplace pas des évaluations de sécurité approfondies ou manuelles.
	DevEco Studio	Environnement de développement intégré (IDE)	Utilitaires de débogage, émulateurs d'appareils et profileurs de performances.	Ne dispose pas de SAST ni de DAST intégrés pour une analyse de sécurité dédiée.
	Programme de bug bounty	Recherche de sécurité externe	Incite des chercheurs indépendants à trouver et signaler des vulnérabilités.	Ne convient pas aux workflows de test internes, continus ou automatisés.
Outils communautaires et émergents	Décompilateurs ArkTS	Rétro-ingénierie	Permet d'inspecter le code compilé et la logique applicative.	Développement à un stade précoce ; nécessite une configuration manuelle.
	Utilitaires de fuzzing	Tests de sécurité des IPC	Teste la communication inter-processus à la recherche de plantages ou de vulnérabilités.	Manque souvent de stabilité et d'intégration CI/CD.
Plateformes de test de sécurité	Ostorlab	Scanner de vulnérabilités automatisé	Analyse automatisée des applications HarmonyOS, y compris des artefacts ArkTS/.abc ; détecte les problèmes de sécurité et les mauvaises configurations courants ; s'intègre aux workflows de test de sécurité.	Complète la revue de sécurité manuelle sans la remplacer.

Analyse automatisée des vulnérabilités de HarmonyOS et de Huawei AppGallery avec Ostorlab

Pour compléter les tests manuels et combler les lacunes des outils existants, l'analyse automatisée peut offrir une couverture cohérente et reproductible des risques propres à HarmonyOS.

Pour les équipes qui ont besoin d'une couverture reproductible et à grande échelle, le scanner de vulnérabilités d'Ostorlab prend directement en charge les applications HarmonyOS et l'analyse de Huawei AppGallery. Les scans ciblent des classes de risques propres à HarmonyOS, notamment :

• Détournement d'Ability exportée et interception d'un Want implicite
• Abus du Distributed Soft Bus (fuite de données entre appareils, invocation d'Ability à distance)
• Injection via l'interface JavaScript d'ArkUI WebView
• Stockage de données non sécurisé dans Preferences ou RDB sans chiffrement
• Clés codées en dur et cryptographie faible contournant HUKS
• Dépassements de tampon et use-after-free dans des modules NAPI natifs
• Paquets HAR/HAP tiers vulnérables dans la chaîne d'approvisionnement

Note : Ces classes de risques sont propres à l'architecture de HarmonyOS et ne sont généralement pas couvertes par les scanners axés sur Android. Pour les définitions, consultez le glossaire officiel de Huawei.

Les vulnérabilités sont livrées avec des preuves solides afin que les équipes puissent vérifier rapidement le risque et prioriser la remédiation. L'outil s'intègre aux pipelines AppSec existants pour la validation avant publication et l'évaluation de sécurité continue, version par version

Vous pouvez scanner une application AppGallery (sans vous connecter) depuis ostorlab.co, ou importer directement des paquets .HAP / .APP via un compte.

Principales fonctionnalités de sécurité de HarmonyOS NEXT

HarmonyOS inclut des fonctionnalités intégrées qui influent sur la manière de sécuriser et de tester les applications. Ce ne sont pas des outils, mais des contrôles au niveau du système qui définissent comment les applications s'exécutent, à quoi elles peuvent accéder et comment les données sont protégées.

Bien que ces fonctionnalités fournissent des mécanismes de sécurité, elles exigent toujours une mise en œuvre correcte et une validation pendant les tests

Sécurité à l'exécution : l'API HarmonyOS SafetyDetect

HarmonyOS fournit SafetyDetect, un framework de sécurité à l'exécution qui permet aux applications d'évaluer l'état de l'appareil à l'exécution. Il comprend quatre capacités principales :

API	Objectif technique	Axe de validation de sécurité
SysIntegrity	Détecte l'état d'un appareil rooté ou altéré.	La vérification se fait uniquement côté appareil. Les auditeurs doivent vérifier si la logique de l'application peut être manipulée localement pour renvoyer un statut « propre », car il n'existe pas d'attestation native côté serveur.
URLCheck	Analyse les URL par rapport au renseignement sur les menaces.	Vérifier que l'application met fin à la session en cas de retour malveillant, plutôt que de simplement consigner un avertissement contournable.
AppsCheck	Détecte les applications malveillantes ou à risque sur l'appareil.	Confirmer que l'application l'utilise pour protéger des actions sensibles (par ex. détecter les outils de capture d'écran) plutôt que pour de la télémétrie passive.
UserDetect	Distingue les interactions humaines des bots.	S'assurer que le jeton obtenu est validé sur le backend afin d'empêcher les contournements par injection via l'API native (NAPI).

Ces API peuvent être intégrées à la logique applicative pour appliquer dynamiquement des décisions de confiance. Cependant, les équipes qui déploient à l'échelle mondiale doivent noter que certaines fonctionnalités de SafetyDetect, notamment la détection liée au Wi-Fi, peuvent être limitées à la Chine continentale. Validez le comportement de l'API dans vos régions de déploiement cibles avant de vous appuyer sur ces contrôles dans une architecture de sécurité de production.

Niveaux de chiffrement des données dans HarmonyOS

HarmonyOS utilise un système de chiffrement à plusieurs niveaux qui permet aux développeurs de contrôler quand les données d'une application sont accessibles. Certaines données sont toujours disponibles, tandis que des données plus sensibles peuvent exiger une authentification de l'utilisateur à chaque accès.

Ce modèle offre plus de contrôle que les paramètres par défaut habituels d'Android et ressemble aux systèmes de protection des données d'iOS.

En pratique, le niveau de chiffrement choisi influe à la fois sur la sécurité et sur la facilité d'accès des utilisateurs à l'application.

Niveau	Nom	Comportement	Usage typique
EL1	Toujours actif	Données accessibles tant que l'appareil est allumé	Données système ou applicatives non sensibles
EL2	Après le premier déverrouillage	Disponibles après le premier déverrouillage de l'appareil et restent accessibles tant que l'appareil fonctionne, même verrouillé	Services en arrière-plan (alarmes, fonctions système)
EL3	Après le déverrouillage initial	Accessibles après au moins un déverrouillage ; restent disponibles même lorsque l'écran est verrouillé	Fonctionnalités à faible sensibilité (accessibilité, données d'urgence)
EL4	Déverrouillé uniquement	Accessibles uniquement lorsque l'appareil est activement déverrouillé ; se reverrouillent à l'extinction de l'écran	Par défaut pour la plupart des données applicatives
EL5	Authentification à chaque accès	Exige une authentification de l'utilisateur à chaque accès aux données	Données très sensibles (identifiants, santé, informations financières)

Correspondance entre les niveaux de chiffrement de HarmonyOS et iOS

Pour faciliter la compréhension, ces niveaux peuvent être comparés de façon approximative à la manière dont iOS gère la protection des données, mais ils ne sont pas équivalents. Sur iOS, il n'existe pas de niveaux EL1–EL5. L'accès aux données dépend plutôt de l'état de l'appareil et de l'authentification. En termes simples : les données système toujours disponibles sur iOS se rapprochent le plus de EL1, les données disponibles après le premier déverrouillage ressemblent à EL2–EL3, les données qui exigent que l'appareil soit activement déverrouillé ressemblent à EL4, et les données qui exigent une authentification à chaque fois (Face ID / Touch ID) se rapprochent le plus de EL5.

Protection du code : obfuscation avec ArkGuard

Les applications HarmonyOS compilées en bytecode Panda peuvent être analysées statiquement si elles sont extraites d'un appareil. Pour relever le niveau face à la rétro-ingénierie, Huawei propose ArkGuard, un outil d'obfuscation qui renomme les symboles et réduit la lisibilité du code pendant le processus de build.

ArkGuard augmente l'effort requis pour l'analyse statique, mais ne doit pas être considéré comme une frontière de sécurité à lui seul.

Une protection efficace pour les applications sensibles exige une approche en couches :

1. Déplacer la logique sensible vers les systèmes backend lorsque c'est possible
2. Vérifier l'intégrité de l'application à l'exécution avec SysIntegrity ou un équivalent
3. Restreindre les fonctionnalités sur les appareils compromis ou rootés
4. Mettre en œuvre des mécanismes d'anti-débogage lorsque le profil de risque le justifie
5. Combiner ArkGuard avec une protection à l'exécution, et non à sa place

Principales vulnérabilités relevées lors des tests de sécurité HarmonyOS

D'après l'architecture de la plateforme et les résultats des scans d'Ostorlab, les principaux domaines de risque des applications HarmonyOS sont :

Risques de sécurité	Description
Détournement d'Ability exportée	Les Abilities de HarmonyOS (comme les Activities/Services d'Android) peuvent être détournées si elles sont exportées de manière inappropriée, ce qui permet à des applications malveillantes de les invoquer et de contourner les contrôles d'accès.
Abus du Distributed Soft Bus	Un DSoftBus (couche de communication entre appareils) mal configuré peut entraîner des fuites de données, l'invocation non autorisée d'Abilities à distance et le détournement de tâches entre appareils.
Injection via ArkUI WebView	Des ponts JavaScript non sécurisés dans ArkUI WebView peuvent permettre à du contenu web non fiable d'appeler des API natives, ce qui exige des adaptations des tests propres à HarmonyOS.
Stockage local de données non sécurisé	Les données sensibles stockées dans Preferences ou RDB sans chiffrement approprié peuvent être exposées sur des appareils compromis ; fréquemment relevé par les scans automatisés.
Risque de chaîne d'approvisionnement via les paquets HAR/HAP	Les dépendances tierces vulnérables dans les modules HAR (Harmony Archive) et HAP (Harmony Ability Package) introduisent des risques de chaîne d'approvisionnement à mesure que l'écosystème grandit.
Cryptographie faible et identifiants codés en dur	Contourner HUKS (Huawei Universal Keystore) ou intégrer des secrets dans le code conduit à une sécurité cryptographique faible et à des identifiants exposés.

Correspondance avec l'OWASP MASVS pour HarmonyOS

Le tableau ci-dessous met en correspondance les catégories de l'OWASP MASVS avec leurs équivalents HarmonyOS afin d'aider les équipes à adapter leurs plans de test existants.

Catégorie OWASP MASVS	Statut HarmonyOS	Notes
MASVS-STORAGE : stockage des données sensibles	S'applique avec adaptation	Les niveaux de chiffrement de HarmonyOS (EL1-EL5) remplacent le modèle de chiffrement par fichier d'Android. Vérifiez que les données sensibles sont stockées en EL4 ou EL5, et non laissées aux valeurs par défaut de la plateforme.
MASVS-CRYPTO : cryptographie	S'applique directement	HUKS (HarmonyOS Universal Keystore) remplace Android Keystore. Recherchez les clés codées en dur, les algorithmes faibles, et vérifiez si HUKS est utilisé correctement ou entièrement contourné.
MASVS-AUTH : authentification	S'applique directement	L'attestation SysIntegrity se fait uniquement côté appareil, contrairement aux jetons vérifiables côté serveur d'Android. La vérification côté backend doit être testée séparément.
MASVS-NETWORK : communication réseau	S'applique directement	Les tests TLS standard s'appliquent. Testez en outre le trafic DSoftBus entre appareils, qui n'a pas d'équivalent Android.
MASVS-PLATFORM : interaction avec la plateforme	S'applique avec adaptation	Le test des Abilities exportées remplace le test d'export des Activities/Services. Le test basé sur les Intents correspond approximativement à l'invocation par Want dans HarmonyOS.
MASVS-CODE : qualité du code	S'applique avec adaptation	Les outils d'analyse statique diffèrent totalement. Les outils basés sur DEX ne s'appliquent pas. Le bytecode Panda nécessite ark_disasm et des décompilateurs spécifiques à ArkTS.
MASVS-RESILIENCE : anti-falsification et obfuscation	S'applique avec adaptation	ArkGuard fournit de l'obfuscation, mais aucune intégrité à l'exécution équivalente à SafetyNet/Play Integrity d'Android au niveau du serveur. Star Shield ne gère que la vérification à l'installation.
Surface d'attaque distribuée / inter-appareils	Aucun équivalent OWASP	DSoftBus, les permissions distribuées et l'invocation d'Abilities entre appareils n'ont pas de correspondance MASVS directe et exigent une modélisation des menaces propre à HarmonyOS.

Foire aux questions

Q : Qu'est-ce qu'une Ability dans HarmonyOS ?
Une Ability est un composant central d'une application HarmonyOS, semblable à une Activity ou à un Service dans Android. Elle représente une fonction précise d'une application, comme un écran ou une tâche en arrière-plan, selon sa conception.

Du point de vue de la sécurité, les Abilities peuvent être exposées à d'autres applications, voire à d'autres appareils. Si elles ne sont pas correctement configurées, elles peuvent être invoquées sans autorisation appropriée, ce qui peut entraîner un comportement inattendu ou une exposition de données.

Q : Qu'est-ce qu'un microkernel, et pourquoi HarmonyOS en utilise-t-il un ?
Un microkernel ne gère que les tâches essentielles comme l'ordonnancement des threads et la communication inter‑processus, tout en déplaçant des services comme la caméra, le réseau et le stockage dans des processus isolés en mode utilisateur. HarmonyOS utilise son propre microkernel, HongMeng, pour limiter les dégâts si un service est compromis, car les attaquants ne peuvent pas facilement pivoter vers le reste du système. Cela contraste avec les noyaux traditionnels basés sur Linux, qui exécutent la plupart des services dans un unique espace noyau privilégié.

Q : Comment la sécurité de HarmonyOS se compare-t-elle à celle d'Android ?
HarmonyOS applique une vérification formelle à certaines parties du système pour prouver que certaines classes de vulnérabilités ne peuvent pas se produire. Parallèlement, son microkernel HongMeng est nettement plus petit qu'un noyau Linux traditionnel, ce qui limite la quantité de code que les attaquants peuvent cibler.

Q : Comment Huawei gère-t-il les mises à jour de sécurité et les correctifs pour les applications et composants système de HarmonyOS ?
Huawei publie chaque mois des mises à jour de sécurité pour HarmonyOS et EMUI qui corrigent plusieurs CVE dans le système et les applications intégrées. Ces correctifs portent sur des problèmes tels que des situations de concurrence de sévérité élevée dans les modules multimédias et des contournements de permissions dans la gestion de fichiers.

Q : Qu'est-ce que Star Shield, et contre quoi protège-t-il ?
Star Shield est un framework de sécurité de HarmonyOS NEXT qui applique, au niveau du système, une évaluation stricte des applications et des vérifications de signature de code. Chaque application doit être signée et vérifiée par Huawei avant son installation, ce qui bloque la plupart des accès non autorisés aux données sensibles et élimine en grande partie les vecteurs de sideloading qui existaient dans les versions précédentes de HarmonyOS compatibles avec Android.

Démarrer avec les scans HarmonyOS sur Ostorlab

Si vous souhaitez exécuter l'analyse automatisée décrite plus haut sur votre propre application HarmonyOS, voici ce qu'il vous faut et jusqu'où va la couverture.

Ce dont vous avez besoin.

• L'application, depuis AppGallery ou sous forme de fichier. Dans le menu New Scan, choisissez AppGallery et recherchez votre application par nom ou par nom de bundle, ou choisissez HarmonyOS App et importez le paquet. Les fichiers HarmonyOS pris en charge sont .HAP, .APP, .RPK, .APK et .AAB. Vous pouvez aussi scanner une application AppGallery depuis ostorlab.co sans vous connecter.
• Un profil de scan. Fast lance une analyse statique rapide, Full lance une analyse statique, dynamique et backend, et Privacy Scan recherche les risques liés à la vie privée. Vous pouvez éventuellement importer un SBOM ou un fichier de verrouillage pour une détection étendue des dépendances.
• Des identifiants de test, pour les parcours connectés. Ajoutez-les à l'étape Set scan credentials afin que l'analyse dynamique atteigne les écrans situés derrière la connexion. Consultez les scans authentifiés pour les types d'identifiants pris en charge.

Ce que vous obtenez. Des vulnérabilités pour les classes de risques HarmonyOS énumérées plus haut dans ce guide, avec les preuves techniques pour les vérifier et les prioriser. Une application HarmonyOS peut aussi être l'actif mobile d'un scan multi-actifs, qui la teste avec ses API, son back end web et son code source en un seul scan ; un scan multi-actifs n'accepte au maximum qu'une application mobile.

Limites de la couverture.

• Le Mobile Shielding Scan, qui valide l'obfuscation, l'anti-falsification, l'anti-débogage et la détection du root ou du jailbreak, est documenté pour les applications Android et iOS.
• Comme le note le tableau des outils ci-dessus, l'analyse automatisée complète la revue de sécurité manuelle des applications HarmonyOS ; elle ne la remplace pas.

Preuves. Présentation des scans d'applications HarmonyOS + des scans Huawei AppGallery décrit le lancement de l'analyse HarmonyOS et AppGallery, et les guides pas à pas pour les scans de store et les scans de fichiers montrent chaque écran.

Prochaine étape. Lancez un scan gratuit de votre application depuis AppGallery sur ostorlab.co, ou réservez une démo pour planifier les tests de vos versions Android, iOS et HarmonyOS.

Conclusion

HarmonyOS offre une architecture de sécurité moderne, dotée de composants fondamentaux solides. Mais les outils, les méthodologies de test et la disponibilité régionale des fonctionnalités de l'écosystème obligent les équipes sécurité à adapter leurs pratiques existantes plutôt qu'à appliquer directement les workflows Android.

Les principaux enseignements pour toute équipe qui teste des applications HarmonyOS :

• Le bytecode Panda exige de nouveaux outils d'analyse statique ; les pipelines DEX existants ne s'appliquent pas
• DSoftBus introduit des surfaces d'attaque inter-appareils absentes d'Android
• Le modèle de confiance de SysIntegrity, limité à l'exécution, exige un renforcement côté backend pour les applications à haut risque
• Les niveaux de chiffrement des données doivent être choisis délibérément, et non laissés aux valeurs par défaut
• L'analyse automatisée avec Ostorlab fournit une couverture de référence sur les classes de risques propres à HarmonyOS

---

Ostorlab est une plateforme de test de sécurité des applications mobiles qui prend en charge Android, iOS et HarmonyOS. Les équipes sécurité utilisent Ostorlab pour évaluer en continu leurs applications et détecter les vulnérabilités tout au long du cycle de vie applicatif. Essayer Ostorlab gratuitement →