Tests d’intrusion d’applications mobiles : ce que l’attaquant atteint avant l’API

Un rapport de test d’intrusion sans vulnérabilité ne signifie pas que votre application mobile est sûre. Cela peut simplement vouloir dire que le testeur n’a jamais quitté la couche API. Si l’équipe sécurité d’un client grand compte ou un auditeur vous a demandé un test d’intrusion de l’application mobile et que vous avez remis un rapport construit à partir de scans d’endpoints d’API, vous avez remis le mauvais document, et cela se verra dès la page deux.

Les tests d’intrusion d’applications mobiles sont une évaluation de sécurité du binaire de l’application elle-même et de l’appareil sur lequel elle s’exécute, pas des serveurs avec lesquels elle communique. Un testeur qualifié extrait l’application, inspecte la façon dont elle stocke les données en local, vérifie si des secrets sont codés en dur dans le code compilé, intercepte et manipule son trafic réseau, puis l’exécute en direct sur un appareil jailbreaké ou rooté pour voir quelles protections tiennent réellement. L’API entre aussi dans le périmètre, mais elle représente la plus petite moitié du travail.

Cette distinction compte, car la plupart des prestataires qui annoncent des “tests d’intrusion mobiles” lancent un scanner d’applications web contre le backend de votre application, emballent le résultat dans un PDF et considèrent la mission terminée. Cela paraît complet. Cela ne répond à aucune des questions qu’un relecteur spécialisé mobile, ou votre propre équipe sécurité, posera réellement.

En quoi les tests d'intrusion mobiles diffèrent-ils des tests web ?

Une application web vit sur un serveur que vous contrôlez. Une application mobile vit sur le téléphone d’un inconnu, et ce téléphone est le matériel de l’attaquant lui-même. Il peut le poser sur son établi, décompiler l’application, y attacher un débogueur et prendre tout le temps qu’il veut. Personne ne dispose de ce type d’accès physique à vos serveurs de production.

Ce seul fait change ce que le test doit couvrir.

Pour la partie API et côté serveur, qui mérite son propre passage dédié, notre liste de contrôle pour les tests d’intrusion d’applications web couvre ce terrain comme il se doit. Cet article reste sur le client, l’appareil et le transport entre les deux, car c’est la surface qu’une mission exclusivement mobile est censée prendre en charge.

Que couvrent réellement les tests d'intrusion d'applications mobiles ?

Toute mission sérieuse de sécurité et de tests d’intrusion d’applications mobiles parcourt la même surface d’attaque centrale, rattachée à OWASP MASVS et au OWASP Mobile Top 10. Voici ce que fait réellement un testeur à chaque couche, et ce qui figure dans le rapport à titre de preuve.

Stockage local des données

Chemin de l’attaquant : Un attaquant disposant de l’appareil, ou d’une copie de sa sauvegarde, extrait le bac à sable de l’application et lit tout ce qu’elle a écrit sur le disque : bases SQLite, fichiers plist ou de préférences partagées, réponses d’API mises en cache, fichiers de journalisation. Si l’un d’eux contient des jetons, des données personnelles ou des données de session en clair, il les obtient sans toucher au moindre serveur.

Ce qui est fourni comme preuve : Un inventaire fichier par fichier du stockage local de l’application avec le contenu non chiffré signalé, des captures des données lisibles extraites directement du système de fichiers de l’appareil, et une note indiquant quelle exigence de stockage OWASP MASVS n’est pas respectée.

Mauvais usage du Keychain et du Keystore

Chemin de l’attaquant : Le Keychain d’iOS et le Keystore d’Android existent pour que les secrets ne restent pas dans des fichiers en clair, mais beaucoup d’applications les utilisent mal, en stockant un jeton avec la mauvaise classe d’accessibilité ou le mauvais niveau de protection, si bien qu’il reste lisible après un jailbreak ou sur un appareil sans écran de verrouillage. L’attaquant se contente de demander l’élément au système d’exploitation et le récupère.

Ce qui est fourni comme preuve : L’entrée précise du keychain ou du keystore, le réglage d’accessibilité ou de protection sous lequel elle a été stockée, et une preuve de concept d’extraction montrant la valeur en clair.

Secrets codés en dur dans le binaire

Chemin de l’attaquant : Clés d’API, secrets de signature ou URL internes se retrouvent compilés directement dans l’application au lieu d’être récupérés à l’exécution. Un testeur décompile le binaire (ou lance simplement strings dessus) et le secret est là, en clair, prêt à être réutilisé directement contre votre backend.

Ce qui est fourni comme preuve : L’extrait décompilé ou désassemblé montrant le secret dans son contexte, et une démonstration de ce que ce secret débloque : un endpoint interne, la clé d’un service tiers, un certificat de signature.

Certificate pinning et interception du trafic

Chemin de l’attaquant : Sans pinning correct, un attaquant fait passer le trafic de l’application par un proxy d’interception sur un appareil qu’il contrôle, lit chaque requête et chaque réponse, et les modifie à la volée, en changeant un prix, un identifiant utilisateur ou un indicateur de permission en plein vol.

Ce qui est fourni comme preuve : Une capture complète des requêtes et réponses de la session d’interception et, lorsque le pinning est présent mais contournable, la technique de contournement précise utilisée (framework de hooking, binaire modifié) accompagnée du trafic ainsi exposé.

Contournement de la détection de jailbreak et de root

Chemin de l’attaquant : Les applications qui vérifient l’état de jailbreak ou de root s’appuient souvent sur une poignée de contrôles bien connus, chemins de fichiers, appels système, listes de paquets, qu’un testeur met en échec avec un outil de hooking prêt à l’emploi en quelques minutes. Une fois ces contrôles contournés, toute autre protection reposant sur l’idée que “cet appareil est de confiance” cesse d’avoir un sens.

Ce qui est fourni comme preuve : Quelle méthode de détection était en place, le contournement exact employé contre elle, et ce qui est devenu accessible une fois le contrôle mis en échec (en général : tout ce qui précède).

Rétro-ingénierie et repackaging

Chemin de l’attaquant : Un testeur décompile l’application pour évaluer quelle part de sa logique métier, de ses contrôles de licence ou de son code anti-altération est exposée et lisible, puis réempaquette une version modifiée (fonctionnalités déverrouillées, publicités retirées, code injecté) et vérifie si elle s’installe et s’exécute comme l’originale.

Ce qui est fourni comme preuve : Le code source décompilé ou sa représentation intermédiaire, une liste annotée de la logique récupérable et, si le repackaging a réussi, l’application modifiée installée et fonctionnelle sur un appareil de test.

Communication entre applications : liens profonds et composants exportés

Chemin de l’attaquant : Les liens profonds et les activités, intents ou fournisseurs de contenu exportés sont la façon dont les applications se parlent, et aussi la façon dont une application malveillante installée sur le même appareil atteint la vôtre, déclenche une action ou récupère des données sans jamais passer par votre interface prévue ni par votre gestion de session. C’est là qu’une bonne partie de la même logique de confiance rompue qui provoque une authentification cassée sur le web réapparaît sur mobile, simplement par une autre porte.

Ce qui est fourni comme preuve : Le composant exporté ou le schéma de lien profond, un appel fonctionnel depuis une application de test sans privilèges qui le déclenche, et ce qui a été exposé ou exécuté en conséquence.

À quoi ressemble un vrai livrable de test d'intrusion mobile

Voici le moyen le plus rapide de distinguer une vraie mission d’un scan automatisé sur lequel on a greffé un générateur de rapport : demandez ce qui a tourné sur un appareil réel.

Un vrai test d’intrusion d’application mobile combine trois choses, pas une :

1. Une analyse statique du binaire décompilé, du code source lorsqu’il est disponible, des fichiers de configuration et des ressources embarquées.
2. Une analyse dynamique de l’application en cours d’exécution, interception du trafic, manipulation à l’exécution, comportement face à des entrées anormales.
3. Une session en direct sur un appareil jailbreaké ou rooté, où le testeur met réellement en échec les protections de l’application en temps réel au lieu de se contenter de signaler qu’elles existent.

Un produit de type scan automatisé plus PDF saute entièrement la troisième étape. Il peut vous dire qu’une chaîne codée en dur ressemble à une clé d’API. Il ne peut pas vous dire si la détection de jailbreak résiste à une véritable tentative de contournement, car cela n’apparaît que lorsque quelqu’un exécute l’application sur un téléphone jailbreaké et essaie.

Demandez à tout prestataire le sommaire du livrable avant de signer. S’il ne comprend pas de session sur appareil en conditions d’exécution avec des captures et des techniques de contournement précises, et si toutes les conclusions semblent sorties d’une liste de règles plutôt que d’un appareil, vous achetez un scan, pas un test d’intrusion d’application mobile. Notre propre processus de tests de sécurité détaille la façon dont nous cadrons et structurons cette mission en trois volets avant le démarrage.

Quand les tests mobiles seuls ne suffisent pas

Un test d’intrusion mobile vous dit ce qu’un attaquant atteint via le client, l’appareil et le transport. Il ne vous dit pas si votre API présente une autorisation défaillante au niveau des objets, une limitation de débit insuffisante ou une faille d’injection qu’un attaquant pourrait exploiter directement, en contournant entièrement l’application et en dialoguant avec votre backend depuis un script. Ce sont des risques réels, et ils exigent leur propre périmètre, pas une note de bas de page dans un rapport mobile.

Si un cadre de conformité ou le questionnaire de sécurité d’un client grand compte demande des “tests de sécurité d’application mobile”, faites confirmer par écrit s’ils attendent l’API comme poste distinct ou dans la même mission. Présumer l’un ou l’autre, c’est ainsi qu’un rapport impeccable finit par ne couvrir que la moitié de ce qui avait réellement été promis.

Comment QAwerk mène un test d'intrusion d'application mobile

Nous cadrons chaque mission de tests d’intrusion d’applications mobiles comme un poste à part entière, analyse statique et dynamique, plus une session en conditions d’exécution sur de vrais appareils jailbreakés et rootés, sans la fondre dans une évaluation web générique et sans l’automatiser de bout en bout. C’est la raison pour laquelle nos clients nous confient des applications fintech de vérification d’identité en amont d’une revue de conformité Google Play ou App Store, et des applications de rencontre et de réseaux sociaux qui stockent des données personnelles plus sensibles que leurs équipes ne l’anticipent : le rapport doit tenir devant quelqu’un qui le lit attentivement, pas seulement avoir l’air complet.

Cette mission s’inscrit dans nos services de tests d’intrusion plus larges, cadrés avec la même tarification transparente en régie, quels que soient les types de tests dont votre application a réellement besoin.

Questions fréquentes

Qu'est-ce qu'un test d'intrusion d'application mobile ?

C’est une évaluation de sécurité du binaire d’une application mobile, de son stockage local et de son comportement au niveau de l’appareil, distincte du test des serveurs auxquels elle se connecte. Un testeur analyse l’application de façon statique, la teste dynamiquement pendant son exécution, puis mène une session en direct sur un appareil jailbreaké ou rooté pour confirmer quelles protections tiennent réellement.

En quoi les tests d'intrusion mobiles diffèrent-ils des tests d'intrusion web ?

Les tests web visent la logique côté serveur à travers le réseau. Les tests mobiles visent un binaire que l’attaquant tient dans la main, et couvrent le stockage local, les secrets codés en dur, le certificate pinning, la détection de jailbreak et la rétro-ingénierie, autant d’éléments sans équivalent web.

Que comprend un test d'intrusion d'application mobile ?

Une revue du stockage local des données, des contrôles du keychain et du keystore, la détection de secrets codés en dur, des tests de certificate pinning et d’interception du trafic, le contournement de la détection de jailbreak et de root, des tentatives de rétro-ingénierie et de repackaging, et des tests de communication entre applications via les liens profonds et les composants exportés.

Un test d'intrusion d'application mobile couvre-t-il aussi l'API backend ?

Certaines missions incluent un passage limité sur l’API, mais l’API mérite son propre périmètre dédié, le même que pour une évaluation web classique. Faites-le confirmer explicitement lorsqu’une exigence de conformité ou une demande client évoque des “tests de sécurité d’application mobile”.

À quelle fréquence une application mobile doit-elle faire l'objet d'un test d'intrusion ?

Cela dépend du rythme de publication et du profil de risque, pas d’un calendrier figé. Notre guide sur la fréquence des tests d’intrusion explique comment définir un rythme adapté à votre situation.