Sécurité offensive
Gouvernance & conformité
Protection des données
L'application mobile est devenue le point de contact principal entre beaucoup d'organisations et leurs utilisateurs, clients comme collaborateurs. Cette proximité a un prix technique : elle déplace une partie de la sécurité hors du périmètre que vous contrôlez, pour l'installer sur un terminal qui appartient à quelqu'un d'autre. Là où une application web garde l'essentiel de sa logique côté serveur, l'application mobile embarque du code, parfois des secrets, et des mécanismes de stockage local. Autant de matière à disposition d'un attaquant patient.
La confusion entre sécurité web et sécurité mobile persiste, y compris dans des organisations qui ont par ailleurs une bonne maturité applicative. Les vecteurs d'attaque diffèrent pourtant sur des points structurants. Un audit applicatif mobile ne se réduit pas au scan d'une URL : il suppose d'entrer dans les mécanismes propres à iOS et à Android, et d'auditer les interfaces de programmation (API) qui font le pont avec vos bases de données. Chez Digitemis, qualifiés PASSI par l'ANSSI, nous menons ces missions sur des applications en production comme sur des versions de préproduction, et c'est presque toujours du côté de l'API que se logent les constats les plus lourds.
L'écart entre un test web et un test mobile
La première erreur de cadrage consiste à transposer une méthodologie web sur un périmètre mobile. Les protocoles de transport se ressemblent, HTTPS des deux côtés, mais les surfaces d'exposition et l'interaction avec le système d'exploitation ne se comparent pas.
L'exécution dans un environnement non maîtrisé
Sur le web, le code s'exécute dans un navigateur qui joue le rôle de bac à sable, avec un modèle de sécurité solide et régulièrement mis à jour. En mobile, l'application est un binaire installé sur le matériel de l'utilisateur. Ce terminal peut être rooté sous Android, jailbreaké sous iOS, instrumenté avec un outil comme Frida. Les protections natives de l'OS tombent alors les unes après les autres. Pour un consultant qui mène un test d'intrusion mobile, l'environnement d'exécution est hostile par défaut. L'application doit être capable de résister seule à l'introspection et à la modification en mémoire.
La persistance des données sur le terminal
Une application web laisse peu de traces locales, cookies et cache mis à part. Une application mobile manipule des bases SQLite, des fichiers de préférences, des caches d'images et des journaux applicatifs. Ces zones de stockage sont le premier endroit où nous regardons, et rarement le dernier : identifiants, jetons d'API, informations de profil, données métier y traînent en clair plus souvent qu'on ne l'imagine. Le test vérifie que ces données sont chiffrées et qu'elles reposent dans les zones prévues par les constructeurs, Keychain sur iOS, Keystore sur Android.
La chaîne de confiance et ses maillons
Le modèle de sécurité mobile implique le développeur, le store, le système d'exploitation et le matériel. Chaque maillon peut être contourné. Une application parfaitement écrite qui embarque une bibliothèque tierce vulnérable offre une porte d'entrée exploitable, sans qu'aucune ligne de son propre code soit en cause. L'analyse porte donc aussi sur la manière dont l'application s'insère dans cet écosystème, en particulier sur la gestion des certificats, qui conditionne la résistance aux attaques de type Man-in-the-Middle.
Le périmètre réel d'un audit mobile
Pour qu'un audit serve à un RSSI ou à un responsable produit, il couvre quatre dimensions qui se tiennent. En laisser une de côté revient à blinder trois portes et à oublier la quatrième.
Le binaire et le code
Le test commence par le binaire, fichier .ipa ou .apk. La décompilation permet de lire la logique métier, de repérer les clés d'API codées en dur et de mesurer le niveau d'obfuscation réel. Quand le code se lit comme un livre ouvert, les vulnérabilités logiques et les endpoints d'administration oubliés se trouvent en quelques heures.
Le stockage local et les secrets système
Chaque fichier créé par l'application sur le disque est inspecté. L'objectif : vérifier qu'aucune information sensible n'est lisible par une autre application installée sur le même terminal. Les journaux applicatifs entrent dans le périmètre, parce qu'ils contiennent trop souvent des traces de débogage laissées après la mise en production.
Le canal de communication
Les échanges entre le mobile et le serveur passent par un proxy d'interception, requête par requête. On vérifie la configuration TLS et, surtout, l'implémentation du certificate pinning. Bien mis en œuvre, il empêche l'interception du trafic même lorsque l'attaquant a réussi à installer un certificat frauduleux sur le téléphone. Mal mis en œuvre, il se contourne en quelques minutes, et cela arrive souvent.
L'API serveur
C'est là que se concentrent les constats critiques. L'application mobile n'est bien souvent qu'une interface graphique : les données et les droits d'accès se jouent côté API. Un test d'intrusion mobile sans volet API, REST ou GraphQL, reste incomplet. L'attaquant se sert de l'application pour comprendre le fonctionnement de l'interface, puis l'attaque directement, sans passer par l'écran ni par les contrôles qu'il porte.
Le binaire, côté client
La partie cliente se traite comme une cible qu'on tente de percer, avec les mêmes outils qu'un attaquant. La méthodologie s'appuie sur l'OWASP MASVS (Mobile Application Security Verification Standard), qui fournit les niveaux de vérification et les cas de test associés.
La résistance à l'ingénierie inverse
Nous testons la réaction de l'application aux outils de rétro-ingénierie. Une application bancaire devrait détecter un terminal compromis, root ou jailbreak, et refuser de fonctionner si un débogueur s'attache au processus. Ces protections n'arrêtent pas un expert déterminé. Elles ralentissent les attaques automatisées et le clonage d'applications, ce qui reste leur objectif.
Les secrets embarqués
Clés de chiffrement symétriques, jetons d'accès à Firebase ou à un bucket S3, identifiants de recette laissés dans une variable de configuration : les ressources et les chaînes de caractères de l'application livrent régulièrement de quoi attaquer directement l'infrastructure cloud. Un secret embarqué dans un binaire distribué sur un store n'est plus un secret.
Les sessions et les jetons
Sur le web, les sessions sont courtes. En mobile, le confort d'usage impose des sessions longues, donc des refresh tokens à durée de vie étendue. Nous regardons où ils sont stockés, comment ils sont renouvelés, et si le serveur sait révoquer une session à distance après le vol d'un terminal. Une mauvaise conception à cet endroit donne à un attaquant un accès durable au compte, sans qu'aucune alerte ne se déclenche.
Les permissions déclarées
L'application réclame-t-elle les contacts, la géolocalisation en arrière-plan ou l'appareil photo sans usage identifié ? Les permissions du manifeste Android et du fichier Info.plist sous iOS sont auditées une par une. Une permission excessive augmente le risque pour l'utilisateur et élargit ce qu'un autre composant du système peut exploiter.
L'API, côté serveur
L'API constitue la surface la plus exposée et la plus rentable pour un attaquant. Dans le cadre d'un test d'intrusion, l'attention porte en priorité sur les vulnérabilités logiques, celles qu'aucun scanner ne remonte.
L'autorisation au niveau de l'objet (BOLA)
Le BOLA (Broken Object Level Authorization) reste la faille numéro un du Top 10 API de l'OWASP. Le principe tient en une manipulation : remplacer /api/user/123 par /api/user/124 et lire les données du voisin. Chaque endpoint est testé pour vérifier que le serveur contrôle systématiquement que l'utilisateur authentifié possède bien des droits sur l'objet demandé, et pas seulement qu'il est authentifié.
L'exposition excessive de données
Certaines API renvoient l'objet utilisateur complet alors que l'écran n'en affiche que le nom. Les réponses JSON sont analysées champ par champ : numéro de téléphone, adresse de facturation, indicateur de rôle administrateur, identifiant interne. Ces données servent ensuite à préparer des attaques ciblées, du phishing à l'élévation de privilèges.
L'absence de limitation de débit
Une API mobile encaisse un trafic légitime intense, ce qui rend le réglage du rate limiting délicat. Nous testons les seuils sur les points sensibles : authentification, réinitialisation de mot de passe, envoi de code à usage unique, requêtes coûteuses en base. Sans limitation, un attaquant teste des milliers de mots de passe ou sature les ressources serveur avec une poignée de requêtes bien choisies.
Les versions obsolètes et les endpoints oubliés
Les API évoluent, mais les versions antérieures restent actives pour les utilisateurs qui ne mettent pas à jour leur application. Ces versions sont rarement maintenues au même niveau de sécurité que la version courante. La recherche de ces shadow APIs et des endpoints de recette restés accessibles fait partie du test. Ils portent souvent des contrôles d'accès plus faibles, parfois inexistants.
Boîte noire, boîte grise, boîte blanche
La qualité des résultats dépend directement du niveau d'information partagé avec l'auditeur. Nous adaptons la configuration à la maturité du projet et à l'objectif de la mission.
En boîte noire, l'auditeur ne dispose que du nom de l'application sur le store. L'approche reproduit fidèlement la position d'un attaquant externe et mesure la surface d'exposition telle qu'elle est visible de l'extérieur. Elle consomme en revanche une part du budget en reconnaissance, au détriment de la profondeur.
La boîte grise est la configuration la plus fréquente. Comptes utilisateurs de différents niveaux, documentation de l'API : le test va directement sur la logique métier, les droits d'accès et les enchaînements complexes. C'est l'équilibre le plus efficace avant une mise à jour majeure.
En boîte blanche, le code source est fourni. L'audit dynamique se couple à une revue de code, ce qui fait apparaître des défauts de conception invisibles autrement : fonction de contournement laissée par une équipe de développement, algorithme de chiffrement écrit maison, contrôle d'accès implémenté au mauvais endroit.
La préparation opérationnelle
Un audit se déroule sur un temps compté. Chaque journée passée à débloquer un accès est une journée qui n'est pas passée à chercher des failles. La préparation côté client détermine donc une bonne part du rendement de la mission.
Il faut d'abord les binaires. APK et IPA non chiffrés, dans une version représentative de ce qui partira en production. Inutile d'attendre la publication sur les stores : plus le test intervient tôt, moins la correction coûte cher. Il faut ensuite au moins deux comptes par niveau de privilège. Sans cela, impossible de tester correctement les accès horizontaux, quand un utilisateur atteint les données d'un autre utilisateur de même rang.
Vient l'environnement. Une préproduction qui reflète fidèlement la production, avec des jeux de données cohérents, donne des résultats exploitables. Si les API sont derrière un pare-feu, un VPN ou un WAF, les accès et les éventuelles exclusions d'adresses IP se règlent avant le démarrage, pas le premier matin.
Reste la documentation. Une spécification d'API à jour, Swagger ou collection Postman, garantit qu'aucun endpoint ne passe au travers. Et si l'application embarque un mécanisme maison, chiffrement applicatif des flux, signature de requêtes, obfuscation spécifique, mieux vaut nous le dire : le temps gagné sur la rétro-ingénierie se réinvestit dans l'analyse de sa robustesse.
La restitution et le retest
Un rapport de test d'intrusion sert à décider quoi corriger, dans quel ordre, avec quelles ressources. La qualité de cette restitution sépare une prestation de conformité d'un accompagnement utile.
Interpréter les criticités CVSS
Les vulnérabilités sont notées selon le CVSS (Common Vulnerability Scoring System). Nous pondérons systématiquement ce score par le contexte métier. Une faille technique classée moyenne devient critique dès lors qu'elle donne accès à des données de santé, permet de valider une transaction financière ou touche un traitement soumis à une obligation réglementaire. Le score brut décrit une mécanique, pas votre exposition.
Prioriser les remédiations
Le plan d'action distingue les corrections rapides à fort effet des chantiers de fond, qui supposent parfois une reprise d'architecture. L'objectif est de faire baisser l'exposition dès les premières semaines sans bloquer les cycles de livraison des équipes de développement. Un plan de correction que personne ne peut absorber ne réduit aucun risque.
La vérification des corrections
Le retest n'est pas une option. Un correctif mal implémenté referme une porte et en entrouvre une autre, et une correction validée en recette ne dit rien de son comportement en production. Une phase de vérification quelques semaines après la remise du rapport permet de confirmer, preuve à l'appui, que les vulnérabilités identifiées ont bien été neutralisées.
Ce qu'il faut retenir
- La sécurité mobile combine deux métiers : l'analyse de binaires et la sécurité des infrastructures serveur. Un audit qui ne couvre qu'un des deux laisse la moitié du risque en place.
- L'OWASP MASVS et l'OWASP API Security Top 10 fournissent la structure de référence pour cadrer la démarche.
- Le stockage local reste l'angle mort le plus fréquent. Le terminal de l'utilisateur ne garde aucun secret.
- Une version d'API obsolète ou un endpoint de recette resté ouvert constitue une porte d'entrée directe, indépendante de la qualité de l'application.
- Le rendement du test dépend de la préparation : binaires, comptes multiples par rôle, accès réseau ouverts, documentation d'API à jour.
- La priorisation des correctifs se pilote par le risque métier, pas par le score technique seul.
Questions fréquentes
Quelle différence entre un scan de vulnérabilités et un test d'intrusion mobile ?
Le scan est automatisé. Il détecte des signatures de failles connues dans les bibliothèques tierces et des erreurs de configuration classiques. C'est utile en continu, dans une chaîne d'intégration, et insuffisant seul. Le test d'intrusion mobile, mené par un consultant, met au jour des failles logiques, des défauts d'autorisation comme le BOLA et des contournements de protections qu'aucun outil ne sait modéliser. Le scan vérifie la serrure ; le pentest essaie d'entrer.
Faut-il tester iOS et Android en même temps ?
Les bases de code diffèrent, Swift ou Objective-C d'un côté, Kotlin ou Java de l'autre, mais la logique métier et l'API consommée sont les mêmes. Tester les deux plateformes permet de vérifier l'homogénéité des protections. Dans les faits, une plateforme est souvent mieux tenue que l'autre, et l'attaquant prend le chemin de moindre résistance. L'audit combiné se justifie donc dès que les deux applications sont publiées.
Combien de temps dure un test d'intrusion mobile et API ?
Cela dépend du nombre d'endpoints, de la richesse fonctionnelle et du niveau de protection embarqué. Une mission couvrant l'analyse statique du binaire, les tests dynamiques d'interception et l'audit de l'API se dimensionne généralement en jours ouvrés sur une à deux semaines. Un périmètre API large, plusieurs rôles métier ou des mécanismes de sécurité maison allongent la charge. Le chiffrage se fait sur la base d'un cadrage, pas d'un forfait.
Avant ou après la publication sur les stores ?
Avant. Un audit mené en fin de développement permet de corriger sans déclencher de mise à jour d'urgence pour une base d'utilisateurs déjà installée, avec les délais de validation des stores en prime. La sécurité applicative reste ensuite un processus continu : toute évolution fonctionnelle majeure, tout changement d'authentification ou de moyen de paiement justifie une nouvelle analyse.
Comment protéger les clés d'API dans le code de l'application ?
Aucune clé sensible ne devrait être stockée statiquement dans un binaire distribué publiquement. Quand une clé est indispensable à l'initialisation d'un service tiers, l'obfuscation ralentit son extraction sans l'empêcher : il faut donc que sa compromission ait un impact limité, ce qui suppose de la cantonner par des restrictions côté fournisseur. Pour les secrets qui comptent, la bonne approche consiste à les obtenir dynamiquement après authentification de l'utilisateur et à les maintenir en mémoire ou dans le compartiment sécurisé du système, Keychain ou Keystore.
Pour aller plus loin
La sécurisation durable d'une application mobile commence en amont du test. Cartographiez vos API et les données qu'elles manipulent, y compris les versions que vous maintenez encore pour compatibilité. Formez vos développeurs aux cas de test du MASVS, en particulier sur l'authentification, le stockage local et la gestion des jetons. Instaurez une revue de code sur les fonctions critiques, paiement, authentification, traitement de données personnelles. Puis planifiez un test annuel, complété par un audit à chaque évolution fonctionnelle majeure.
Nos tests d'intrusion sont réalisés dans le cadre de notre qualification PASSI délivrée par l'ANSSI, avec la même exigence sur l'analyse du binaire et sur la gouvernance des API. Nous ne vendons pas d'outils et n'éditons pas de logiciels : notre évaluation reste indépendante des solutions que vous déployez. Si vous préparez un audit sur vos applications iOS et Android, contactez-nous pour en cadrer le périmètre.