La dernière fois qu'un développeur m'a montré son app, il était fier : 40 000 téléchargements, une note de 4,7, zéro crash signalé. Je lui ai demandé où était stocké le token d'authentification. Il m'a répondu « dans les préférences, pourquoi ? ». Deux heures plus tard, je lisais ce token en clair sur un émulateur rooté, avec le compte administrateur qui allait avec.
Ce n'est pas un cas isolé. C'est même la norme. Auditer la sécurité numérique d'une application mobile, ce n'est pas passer un antivirus sur un téléphone : c'est traquer méthodiquement tout ce qu'un attaquant peut faire avec votre app une fois qu'elle est entre les mains de quelqu'un qui n'a aucune raison de jouer le jeu. Et le point de départ, celui que presque tout le monde rate, c'est de comprendre que votre app vit sur un appareil que vous ne contrôlez pas.
Points clés à retenir
- Un audit sérieux combine analyse statique, analyse dynamique et tests réseau — les trois, pas l'un ou l'autre.
- Le référentiel de référence s'appelle MASVS (les exigences) et MASTG (les techniques pour les vérifier) ; l'OWASP Mobile Top 10 sert à prioriser, pas à cocher.
- Le stockage local et les échanges réseau sont les deux sources de fuite les plus fréquentes.
- Un rapport sans score de criticité ni plan de remédiation daté ne vaut rien.
- Sur Android, l'APK est souvent reconstruit et resigné en quelques minutes. Ne pariez jamais sur l'obfuscation seule.
Pourquoi auditer la sécurité d'une application mobile change tout (et pourquoi ça ne se voit pas)
Une app mobile, c'est un morceau de votre backend posé chez l'utilisateur. Le code, les clés d'API, la logique métier, parfois les identifiants de connexion tiers : tout ça voyage dans un fichier que n'importe qui peut décompresser.
Sur Android, un APK est une archive ZIP. On la renomme, on l'ouvre, on récupère le dex, on le décompile. Sur iOS, un IPA se déballe pareil. Aucune magie, aucune compétence rare. J'ai vu un stagiaire sortir une clé d'API AWS en clair d'une app bancaire en une après-midi.
Ce qui change par rapport à un audit web classique
Sur le web, vous contrôlez le serveur. Vous patchez, vous redéployez, l'utilisateur n'a rien à faire. Sur mobile, non. Trois contraintes cassent tout :
- Les vieilles versions restent installées. Des mois, parfois des années, parce que personne ne met à jour une app qu'il ouvre deux fois par mois.
- L'appareil peut être compromis (root, jailbreak, hooking avec Frida). Votre code s'exécute alors dans un environnement hostile qui peut lire votre mémoire.
- Le réseau n'est jamais fiable. Un proxy entre votre app et votre serveur, et tout ce qui n'est pas épinglé se fait intercepter.
Le point numéro deux est celui qu'on sous-estime le plus. Je me souviens d'un client qui m'avait dit, très sûr de lui : « de toute façon, il faut être rooté pour nous attaquer ». Sous-entendu : c'est rare, donc on s'en fiche. Sauf que rooter un Android prend dix minutes avec un tutoriel, et qu'un utilisateur rooté est exactement celui qui va tester les limites de votre app.
La méthodologie d'un audit mobile, étape par étape
Il n'existe pas de recette unique, mais il existe un enchaînement qui fonctionne. Je le pratique dans cet ordre parce que chaque phase nourrit la suivante : ce que je trouve en statique me donne les cibles de mes tests dynamiques, et ce que je trouve en dynamique me renvoie vers du code précis.
Phase 1 — l'analyse statique (le squelette)
On récupère le binaire et on le dépiaute. Objectif : comprendre l'architecture, repérer les secrets, voir ce qui est protégé et ce qui ne l'est pas.
- Décompiler l'APK ou l'IPA et lire le manifeste : permissions demandées, composants exportés (activities, services, receivers), policies de sécurité réseau.
- Fouiller les ressources et les chaînes de caractères à la recherche de clés, d'URLs internes, de comptes de test oubliés.
- Vérifier le stockage : SharedPreferences, base SQLite, fichiers de cache, Keychain côté iOS.
- Contrôler la présence d'obfuscation, de détection de root, d'anti-debug.
Cette phase se fait à froid, sans lancer l'app. C'est rapide et ça remonte souvent 60 à 70 % des problèmes réels.
Phase 2 — l'analyse dynamique (le comportement)
Là, on exécute. Sur un appareil rooté ou un émulateur instrumenté, on branche un outil de hooking et on regarde ce qui se passe en mémoire : les clés de chiffrement, les données déchiffrées, les appels de fonctions sensibles. On manipule aussi l'app pour voir comment elle réagit quand on lui ment.
Deux tests que je fais systématiquement, et qui font mal :
- Le test de contournement. On essaie de faire croire à l'app qu'elle tourne sur un appareil propre, ou qu'elle a déjà validé un contrôle. Une app qui parie toute sa sécurité sur « l'utilisateur ne peut pas modifier ma logique » perd en général ce pari.
- Le test de réaction à la falsification. On modifie le binaire, on le resign, on le réinstalle. Si elle démarre sans broncher, vous avez un problème.
Phase 3 — les tests réseau
On place un proxy d'interception entre l'app et son backend, on installe un certificat, et on lit tout le trafic. Ce qui compte ici :
- Le chiffrement est-il réel (TLS correct, pas de downgrade possible) ?
- Y a-t-il épinglage de certificat (certificate pinning) ? Et si oui, résiste-t-il à un contournement en quelques minutes ?
- Les données d'authentification circulent-elles dans des en-têtes propres ?
- Le backend vérifie-t-il les droits côté serveur, ou fait-il confiance à ce que l'app lui envoie ?
Cette dernière question est la plus vicieuse. Beaucoup d'équipes valident les permissions dans l'app et jamais côté serveur. Résultat : on intercepte la requête, on change l'identifiant du compte, et on lit les données de quelqu'un d'autre. J'ai vu exactement ça sur une app de mutuelle en 2024. Le rapport a fait remonter le projet de mise en production de six semaines.
| Type d'analyse | Ce qu'on cherche | Outil typique | Quand l'utiliser |
|---|---|---|---|
| Statique | Secrets, permissions, logique exposée | Décompilateur, grep, analyseur de manifeste | En premier, toujours |
| Dynamique | Données en mémoire, contrôles contournables | Instrumentation, hooking | Une fois le périmètre cartographié |
| Réseau | Chiffrement, épinglage, logique serveur | Proxy d'interception | En parallèle du dynamique |
| Tests d'intrusion | Scénarios d'attaque chaînés | Combinaison des trois précédents | En clôture, pour valider |
Choisir un prestataire d'audit : les critères qui comptent vraiment
Vous pouvez tout faire en interne. Si vous avez l'équipe, faites-le. Mais dans la majorité des cas que je croise, une PME n'a ni le temps ni les compétences pour décompiler un IPA et instrumenter un runtime. Elle confie ça à l'extérieur. Et là, le marché est un peu le far west.
Ce qu'il faut exiger dans le rapport
Un rapport d'audit, ce n'est pas une liste de vulnérabilités. C'est un document qui doit vous permettre de décider quoi corriger dans quel ordre. Trois éléments non négociables :
- Un score de criticité par faille (type CVSS) et une explication de son impact concret. « Stockage non sécurisé » ne veut rien dire seul. « Token d'authentification lisible par une app tierce, permettant la prise de contrôle de compte » veut tout dire.
- Un plan de remédiation chiffré et daté, avec un effort estimé par correctif.
- La mention du périmètre exact : quelle version testée, quels appareils, ce qui n'a pas été testé.
MASVS, MASTG, OWASP Mobile Top 10 : qui fait quoi
On mélange souvent les trois. Ce sont pourtant des objets différents :
- L'OWASP Mobile Top 10 est une liste des dix familles de risques les plus courants. Utile pour communiquer en interne, pour prioriser.
- MASVS est le référentiel d'exigences de sécurité. C'est la grille de contrôle : qu'est-ce qu'une app correcte doit garantir ?
- MASTG est le guide technique. C'est la boîte à outils : concrètement, comment je vérifie telle exigence sur Android ou sur iOS.
Un bon prestataire vous livre un résultat mappé sur MASVS. Si son rapport ne cite que des catégories floues et aucune exigence vérifiée, méfiance. Demandez-lui aussi comment il gère ses propres données : un auditeur qui stocke vos binaires sur un serveur non chiffré, c'est une fuite qui attend son heure.
Les erreurs que je vois revenir, encore et encore
Spoiler : ce ne sont presque jamais des failles exotiques. Ce sont les mêmes bêtises, à l'identique, depuis des années.
Erreur 1 : croire que le client est un environnement de confiance. Toute validation de droits doit exister côté serveur. Sans exception.
Erreur 2 : laisser des secrets dans le code. Une clé d'API dans un APK est une clé publique. Si vous en doutez, décompressez votre propre app et regardez.
Erreur 3 : confondre obfuscation et sécurité. L'obfuscation ralentit un attaquant motivé. Elle ne l'arrête pas. Et elle ne protège rien si la logique sensible est côté client.
Erreur 4 : tester uniquement la dernière version. Les utilisateurs, eux, ne sont pas à jour. Si votre API accepte les requêtes d'une version vieille de deux ans, cette version est votre vraie surface d'attaque.
Franchement, la quatrième est celle qui m'agace le plus. On passe des semaines à durcir la version 4.0 pendant que la 2.8, encore installée sur 15 % des appareils, laisse passer tout le trafic parce que l'épinglage n'y existait pas encore. Corriger la nouvelle version ne répare pas l'ancienne qui parle toujours à votre serveur.
À quelle fréquence auditer, et combien ça coûte
Un audit, ce n'est pas une vaccination. Ce n'est pas « fait une fois, tranquille pour cinq ans ».
Ma règle, après plusieurs années à voir des équipes se faire surprendre : un audit complet avant la première mise en production, puis un audit de suivi à chaque évolution majeure de l'architecture ou des flux d'authentification. Entre les deux, une vérification automatisée dans la chaîne d'intégration continue attrape les régressions faciles : secret oublié, permission ajoutée sans raison, chiffrement désactivé pour déboguer.
Sur les délais, comptez deux à quatre semaines pour une app de complexité moyenne, périmètre serré. Sur le coût, c'est très variable — mais méfiez-vous des offres trop basses. Un audit à quelques milliers d'euros qui vous livre trois pages Word, c'est de l'argent perdu et un faux sentiment de sécurité, ce qui est pire que pas d'audit du tout.
Et surtout : prévoyez le budget de correction avant de lancer l'audit. Découvrir quinze failles critiques sans avoir le temps de les corriger, c'est se retrouver avec un rapport que personne ne veut lire et une app qui reste trouée.
Par où commencer demain matin
Si vous ne devez retenir qu'une chose de cet article, c'est celle-là : commencez par ce qui ne coûte rien. Décompressez votre propre APK aujourd'hui. Ouvrez les préférences et les bases locales sur un appareil de test. Branchez un proxy et regardez passer vos propres requêtes. Dans 80 % des cas, la première heure de ce travail remonte déjà quelque chose qui ne devrait pas être là.
Le reste — instrumentation, tests d'intrusion, contournement de protections — viendra après, quand vous saurez où taper. Ce qui m'inquiète, ce n'est pas que les développeurs ignorent ces techniques. C'est qu'ils pensent que quelqu'un d'autre s'en occupe. Personne ne s'en occupe. Votre app est en ligne, elle parle à votre serveur, et elle attend qu'on vienne la lire.
