OWASP Mobile Top 10 2024 : les dix risques des applications mobiles

Le Top 10 OWASP des risques des applications mobiles a été refondu en 2024, huit ans après son édition précédente. Huit ans, sur ce terrain, c’est une génération de systèmes d’exploitation, deux générations de magasins d’applications et l’arrivée des chaînes de construction automatisées. Le classement qui en sort est très différent de celui de 2016 : le stockage local, longtemps deuxième préoccupation, tombe au neuvième rang, et les deux premières places vont à l’usage des identifiants et à la chaîne d’approvisionnement.

→ Lire l’explication complète de la marmotte

Les dix risques de l’édition 2024

Code	Titre officiel	Traduction
M1	Improper Credential Usage	Usage incorrect des identifiants
M2	Inadequate Supply Chain Security	Sécurité insuffisante de la chaîne d’approvisionnement
M3	Insecure Authentication/Authorization	Authentification et autorisation non sécurisées
M4	Insufficient Input/Output Validation	Validation insuffisante des entrées et des sorties
M5	Insecure Communication	Communication non sécurisée
M6	Inadequate Privacy Controls	Contrôles de vie privée insuffisants
M7	Insufficient Binary Protections	Protections insuffisantes du binaire
M8	Security Misconfiguration	Mauvaise configuration de sécurité
M9	Insecure Data Storage	Stockage de données non sécurisé
M10	Insufficient Cryptography	Cryptographie insuffisante

Les codes de cette liste n’ont pas de millésime collé au numéro, contrairement au Top 10 web ou au Top 10 LLM. « M3 » désigne donc l’authentification en 2024 et la communication non sécurisée en 2016, sans que rien dans le code ne le signale. Écrire l’année à côté est ici encore plus nécessaire qu’ailleurs.

Ce qui a changé depuis 2016, et ce que ça dit du terrain

M1 « Improper Platform Usage » a disparu, M1 est devenu « Improper Credential Usage ». L’ancienne première place sanctionnait le mauvais usage des mécanismes offerts par le système — permissions, trousseau, interfaces de plateforme. Les systèmes mobiles se sont durcis et leurs interfaces se sont clarifiées ; ce qui reste, et qui prend la tête, est beaucoup plus bête : des identifiants codés en dur dans l’application, des clés d’interface de programmation embarquées dans le binaire, des jetons réutilisés indéfiniment. Un binaire mobile est distribué à des millions d’appareils que l’éditeur ne contrôle pas, et il se décompile. Y mettre un secret est une publication, avec un délai. Le site traite le sujet côté dépôt dans la prévention des secrets dans le code source.

M2 « Inadequate Supply Chain Security » est entièrement nouvelle, et sa deuxième place est le signe le plus clair de l’évolution du terrain. En 2016, une application mobile était pour l’essentiel écrite par l’équipe qui la livrait. En 2024, elle agrège des bibliothèques d’analytique, de publicité, de cartographie, d’authentification tierce et de rapport de plantage, chacune avec ses propres dépendances et ses propres accès. Le mouvement est le même que celui du Top 10 web, qui a créé sa catégorie A03 pour la même raison. Les mécanismes se recoupent : dépendances transitives, inventaire logiciel, confiance accordée aux mises à jour automatiques.

Authentification et autorisation fusionnent en M3. L’édition 2016 les séparait en M4 et M6. Le regroupement a un sens précis sur mobile : le client ne peut rien décider. Un contrôle d’autorisation implémenté dans l’application est contournable par définition, puisque l’attaquant exécute l’application. La seule frontière qui tient est côté serveur, et la seule question utile est de savoir laquelle des deux décisions a été laissée au téléphone.

M7 absorbe la rétro-ingénierie et l’altération de code. Les anciennes entrées M8 « Code Tampering » et M9 « Reverse Engineering » deviennent « Insufficient Binary Protections ». La reformulation est honnête : on ne protège pas un binaire contre son propriétaire, on augmente seulement le coût de l’analyse et de la modification. L’obfuscation et la détection d’altération ne sont pas des contrôles de sécurité au sens de M3 ou M5, mais des ralentisseurs. Les traiter comme des contrôles conduit à l’erreur classique — fonder une décision de sécurité sur le fait que l’application n’a pas été modifiée, ce que l’application elle-même est bien mal placée pour affirmer.

M6 « Inadequate Privacy Controls » est nouvelle. C’est l’entrée qui sort du périmètre technique habituel pour nommer un risque que huit ans de réglementation ont rendu concret : collecter, conserver et transmettre des données personnelles sans contrôle proportionné. Sur mobile, la tentation est structurelle, puisque le système offre un accès à la position, aux contacts, aux capteurs et aux identifiants d’appareil, et que les bibliothèques tierces de M2 en demandent volontiers leur part.

Le stockage local tombe de la deuxième à la neuvième place, et la cryptographie insuffisante de la cinquième à la dixième. Ce n’est pas que le sujet ait disparu : c’est que les systèmes mobiles fournissent désormais un chiffrement d’appareil, un trousseau matériel et des interfaces de stockage sûres par défaut, ce qui a sorti ce risque de l’ornière où il était. Le site décrit ces mécanismes dans le stockage sécurisé sur mobile. Ce recul relatif est une bonne nouvelle, et la seule de cette liste.

M4, M5 et M8 : la part qui ressemble au web, et celle qui n’y ressemble pas

Trois entrées portent des noms que le Top 10 web emploie aussi, et il serait commode d’en conclure qu’elles disent la même chose. Elles ne le disent pas.

M4, la validation des entrées et des sorties, remplace l’ancienne entrée M7 « Client Code Quality ». Sur mobile, la frontière de confiance ne passe pas seulement entre l’utilisateur et l’application : elle passe aussi entre l’application et le système, entre l’application et les autres applications installées, et entre l’application et les contenus qu’elle affiche. Une donnée qui arrive par un lien profond, par un presse-papiers, par un fichier partagé ou par un composant d’affichage web embarqué est une entrée non fiable au même titre qu’un champ de formulaire. Côté sortie, le piège est le composant web embarqué : un contenu injecté dans une vue qui dispose d’un pont vers le code natif ne reste pas dans la vue.

M5, la communication non sécurisée, ne se résume pas à « utiliser TLS ». Le transport chiffré est, sur mobile, presque toujours en place : ce qui manque est la validation. Une application qui accepte un certificat quelconque parce qu’un développeur avait désactivé le contrôle pour tester un environnement de recette est le cas le plus fréquent, et il survit aux revues de code parce que la ligne fautive est dans une configuration de construction, pas dans le code métier. La contre-mesure la plus citée — l’épinglage de certificat — règle un problème et en crée un autre : une application épinglée sur un certificat qui expire devient inutilisable pour tous ses utilisateurs simultanément, et la correction passe par le magasin d’applications. Le site traite ce compromis dans l’épinglage de certificat et son coût opérationnel.

M8, la mauvaise configuration, est l’entrée la plus discrète et celle qui se détecte le plus vite. Un drapeau de débogage resté actif dans la version publiée, une sauvegarde automatique du répertoire de l’application vers un service cloud, une permission déclarée dans le manifeste et jamais utilisée, un composant exporté par défaut : rien de tout cela n’exige d’analyse dynamique. Le manifeste et les paramètres de construction suffisent, et c’est exactement ce qu’un attaquant lit en premier.

Ce qui n’a pas été retenu, et c’est documenté

Le référentiel publie la liste des risques écartés de cette édition tout en indiquant qu’ils pourraient revenir : fuite de données, secrets codés en dur, contrôle d’accès non sécurisé, écrasement et traversée de chemin, points d’entrée non protégés — liens profonds, activités, services — et partage dangereux.

Cette liste des recalés est plus instructive que le classement lui-même, parce qu’elle montre le recouvrement. « Secrets codés en dur » n’a pas été retenu comme entrée propre, mais c’est l’essentiel de M1. « Fuite de données » est un symptôme dont les causes se répartissent entre M4, M5, M6 et M9. Les points d’entrée non protégés relèvent de M8. Le découpage retenu privilégie donc la cause sur le symptôme, comme le Top 10 web, sans que ce soit annoncé aussi explicitement.

La maturité du document, et avec quoi le compléter

Deux observations de forme, qui décident de la façon de citer ce référentiel. D’abord, le dépôt du projet range les pages de risques de l’édition 2024 dans un répertoire nommé d’après 2023 : la liste a circulé comme version préliminaire avant d’être promue en version finale, et la numérotation est restée. Ensuite, la page du projet annonce des mises à jour « à venir bientôt » depuis la publication. Le document fait référence — c’est le seul de son objet — mais il n’a pas la cadence du Top 10 web ni sa base de données.

Le complément naturel, et il est de meilleure qualité, est la paire MASVS / MASTG : le Mobile Application Security Verification Standard, en version 2.1.0, qui transforme ces thèmes en exigences vérifiables, et le Mobile Application Security Testing Guide, qui décrit comment les tester. C’est la même articulation qu’entre le Top 10 web et l’ASVS : la liste de risques sert à décider de quoi on parle, le standard de vérification sert à décider ce qu’on exige et avec quelle preuve. Une application mobile qui « respecte le Mobile Top 10 » sans matrice MASVS derrière ne respecte rien de vérifiable.

Du côté du transport, la validation du certificat client sur un terminal mobile ou embarqué complète utilement M5, qui ne traite que le sens serveur. La façon de citer les Top 10 de l’OWASP selon leur maturité est traitée dans la page chapeau.

🐝 Ce qui arrive si on s’en passe

Sans traiter M1, une clé d’interface de programmation embarquée dans le binaire est extraite par simple décompilation : elle est publiée, à retardement, sur autant d’appareils que l’application compte d’installations, et sa rotation exige une nouvelle version passée en revue par le magasin. Sans inventaire des bibliothèques tierces, une dépendance d’analytique ajoutée pour une campagne continue de transmettre des identifiants d’appareil deux ans plus tard, sans qu’aucune revue ne la rouvre. Sans contrôle d’autorisation côté serveur, une vérification implémentée dans l’application est contournée par qui exécute l’application, c’est-à-dire par tout le monde, et les journaux serveur ne distinguent pas l’appel légitime de l’appel forgé. Sans comprendre que les protections du binaire sont des ralentisseurs et non des contrôles, une décision de sécurité finit adossée à la détection d’altération, que l’application compromise affirme toujours avoir réussie. Sans exigence vérifiable derrière les dix entrées, la conformité se résume à dix cases cochées, et une régression de configuration retirant la validation du certificat serveur ne se voit qu’à l’incident.

🦫 Explication de la marmotte 🍫

Une association internationale de spécialistes publie une liste des dix problèmes de sécurité les plus fréquents dans les applications pour téléphones et tablettes. La version actuelle date de 2024 ; la précédente datait de 2016, et l’ordre a beaucoup changé.

La différence principale avec un site web est que l’application se trouve sur un appareil qui n’appartient pas à son éditeur. Quelqu’un peut l’examiner tranquillement, lire ce qu’elle contient et modifier son fonctionnement. Tout ce qui est écrit dans l’application est donc lisible : un mot de passe ou une clé d’accès placés à l’intérieur finiront par être trouvés. C’est désormais le premier problème de la liste.

Le deuxième est l’origine des morceaux de logiciel qu’on assemble. Une application moderne contient de nombreuses bibliothèques fournies par d’autres sociétés — pour les statistiques, la publicité, les cartes, les rapports de plantage. Chacune accède à des données du téléphone, et chacune peut être modifiée par un attaquant qui aurait pris le contrôle de son auteur.

Viennent ensuite la vérification de l’identité, qui doit être faite par un serveur et non par l’application, la vérification de ce qui entre et sort, la protection des échanges sur le réseau, et le respect de la vie privée — un téléphone donne accès à la position, aux contacts et aux capteurs.

Deux problèmes qui étaient très hauts dans la liste de 2016 sont descendus : l’enregistrement des données sur l’appareil et le choix des méthodes de chiffrement. Ce n’est pas qu’ils aient cessé de compter : les systèmes des téléphones font aujourd’hui une bonne partie du travail à la place des développeurs.

Pages voisines

La citent

OWASP Kubernetes Top 10 2025 : les dix risques d'un cluster

OWASP Mobile Top 10 2024 : les dix risques des applications mobiles

Elle cite

: les deux pages se citent l’une l’autre.

OWASP Mobile Top 10 2024 : les dix risques des applications mobiles

OWASP Mobile Top 10 2024 : les dix risques des applications mobiles

Les dix risques de l’édition 2024

Ce qui a changé depuis 2016, et ce que ça dit du terrain

M4, M5 et M8 : la part qui ressemble au web, et celle qui n’y ressemble pas

Ce qui n’a pas été retenu, et c’est documenté

La maturité du document, et avec quoi le compléter

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines