Un développeur m'a montré son app de gestion de dépenses l'an dernier. Code propre, UI soignée, 40 000 téléchargements. Je lui ai demandé où il stockait le token d'authentification. Réponse : SharedPreferences, en clair. N'importe qui avec un téléphone rooté pouvait lire la session d'un utilisateur en trois minutes. Il ne le savait pas. Et le pire, c'est qu'il avait lu trois guides sur la sécurité mobile avant de publier.
Voilà le problème avec la sécurisation des applications mobiles : on trouve partout des listes de bonnes intentions, jamais les failles réelles ni comment les fermer. Sécuriser ses applications mobiles contre les failles courantes, ce n'est pas cocher une case dans un audit. C'est connaître les sept ou huit trous dans lesquels tout le monde tombe, et savoir dans quel ordre les boucher quand on n'a ni le temps ni le budget d'une équipe de sécurité dédiée.
Points clés à retenir
- Les failles mobiles ne sont pas exotiques : elles se répètent, et les mêmes huit erreurs reviennent dans la quasi-totalité des apps que j'ai auditées.
- Le stockage local non chiffré arrive en tête. C'est aussi le correctif le moins coûteux à mettre en place.
- Google Play Protect et les antivirus grand public ne vous protègent que très partiellement : ils vérifient l'app avant l'installation, pas ce qu'elle fait de vos données après.
- Un audit de sécurité mobile utile tient en priorisation par criticité, pas en checklist de 200 lignes.
- Côté utilisateur, trois réglages suffisent à éliminer l'essentiel du risque réel de piratage au quotidien.
Les failles courantes des applications mobiles, classées par ce qu'elles rapportent à un attaquant
Je classe toujours les vulnérabilités selon une seule question : combien de temps un attaquant met-il à en tirer quelque chose d'exploitable ? Ça évince 80 % du bruit. Ce qui reste, ce sont les failles qui font réellement tomber des apps en production.
Le stockage local en clair
Sur Android comme sur iOS, une app écrit des données dans un espace qui lui est propre : SharedPreferences et bases SQLite côté Android, fichiers plist et NSUserDefaults côté iOS. Rien n'empêche d'y mettre un mot de passe, un token, un numéro de carte. Et rien ne le chiffre par défaut.
Ma règle : tout ce qui identifie un utilisateur (token de session, clé d'API, données de paiement) passe par le Keychain iOS ou un EncryptedSharedPreferences Android. Le reste peut rester en clair sans drame. Un mauvais token volé sur un appareil rooté, c'est une session détournée sans jamais toucher à votre serveur.
Les communications mal vérifiées
Avoir une URL en https:// ne suffit pas. Une app qui accepte n'importe quel certificat serveur est vulnérable à une attaque de l'intercepteur : un proxy sur le même réseau Wi-Fi se fait passer pour votre backend et lit tout. J'ai vu ça dans un hôtel, en testant mon propre projet sur le Wi-Fi public. En dix minutes, le token d'un collègue était dans mon terminal.
Le remède s'appelle le certificate pinning : l'app n'accepte qu'un certificat connu d'avance. Implémentation un peu pénible, mais incontournable pour toute app qui manipule des données sensibles.
Injection et validation côté serveur absente
Beaucoup d'apps mobiles traitent le serveur comme une source de confiance, et inversement. Erreur classique : valider les entrées dans l'app avant de les envoyer. Sauf qu'un attaquant n'utilise pas votre app, il parle directement à votre API. Toute validation côté client doit exister côté serveur, sans exception.
Le reverse engineering et le tampering
Un APK se décompile. Les clés d'API laissées en dur dans le code source se retrouvent en clair sur GitHub ou dans des outils d'analyse en quelques minutes. Je l'ai fait sur ma propre app, par curiosité : ma clé d'accès à un service tiers était visible à la vingtième ligne. Trois cents euros de quotas consommés par des inconnus avant que je m'en rende compte.
La parade : jamais de secret dans le binaire. Les secrets vivent sur un backend, l'app ne fait que consommer des jetons courts et révocables.
Les permissions excessives et les composants exposés
Une app de recettes n'a pas besoin de lire vos SMS. Une app de notes n'a pas besoin de votre position. Chaque permission demandée est une porte ouverte si l'app est compromise. Côté développeur, on retire tout ce qui n'est pas strictement nécessaire. Côté utilisateur, on refuse sans état d'âme.
Les dépendances obsolètes
Votre code peut être impeccable et votre app vulnérable quand même, parce qu'une bibliothèque tierce embarque une faille connue. Les SDK publicitaires sont les pires : ils accèdent au réseau, au stockage et parfois à l'identifiant publicitaire. Chaque dépendance est un risque qui n'est pas le vôtre jusqu'à ce qu'il le devienne.
Dans quel ordre corriger quand on est seul sur le projet
Personne n'a le luxe de tout corriger d'un coup. Voilà l'ordre que j'applique aujourd'hui, après avoir perdu du temps à faire l'inverse.
- D'abord les secrets exposés : clés en dur, tokens en clair. C'est le correctif le plus rapide et l'impact le plus immédiat.
- Ensuite le chiffrement du stockage local et le pinning TLS. Ces deux chantiers éliminent la majorité des scénarios d'exploitation sur appareil compromis.
- Puis la validation serveur. Refonte plus lourde, mais c'est elle qui ferme les injections.
- Enfin, l'hygiène des dépendances et des permissions. Plus une question de discipline continue que de sprint.
Sur un projet que je suivais, réordonner les chantiers dans cet ordre a fait passer le délai d'audit de trois semaines à neuf jours. Non pas qu'on ait moins travaillé : on a arrêté de polir des détails pendant que la porte d'entrée était ouverte.
Les tests concrets, pas les intentions
Un audit sans outil, c'est de la philosophie. Trois familles d'outils font 90 % du travail réel :
- MASVS et MASTG, les référentiels OWASP pour mobile : un standard de vérification et un guide de test. Je m'en sers comme grille de lecture, pas comme dogme.
- MobSF pour l'analyse statique et dynamique d'un APK ou d'un IPA. Décompilation, recherche de secrets, comportement au runtime. Gratuit, et ça sort en cinq minutes ce qu'on trouve en trois heures à la main.
- Frida pour l'instrumentation dynamique. On modifie le comportement de l'app au runtime pour tester la résistance au tampering. Plus rustique, mais c'est la seule façon de vraiment savoir si vos protections tiennent.
Un test d'intrusion mobile sérieux, concrètement, c'est deux à cinq jours de travail selon la surface de l'app. Pas une ligne dans un devis, une vraie phase avec des livrables. Et ça se refait à chaque changement majeur d'authentification ou de paiement.
Comparer les niveaux de protection selon le profil
Toutes les apps n'ont pas besoin du même niveau. Voilà comment je répartis les efforts selon ce que manipule l'application.
| Type d'application | Protection minimale | Effort réaliste | Priorité n°1 |
|---|---|---|---|
| App de contenu sans compte | HTTPS + dépendances à jour | Quelques heures par trimestre | Hygiène des bibliothèques |
| App avec comptes utilisateurs | Stockage chiffré + pinning TLS | 2 à 3 jours au démarrage | Protection des tokens |
| App de paiement ou santé | Tout le précédent + anti-tampering | 1 à 2 semaines + audit annuel | Conformité et tests d'intrusion |
| App embarquée / IoT compagnon | Chiffrement bout en bout + rotation de clés | Continu, pas ponctuel | Gestion du cycle de vie des clés |
Le piège classique : appliquer le niveau « paiement » à une app de recettes. On dépense un budget démesuré sur des menaces improbables, pendant que le vrai trou (un token en clair) reste béant. J'ai fait cette erreur au tout début. Six semaines passées à implémenter de l'obfuscation avancée, pour découvrir ensuite que les mots de passe étaient stockés en clair.
Côté utilisateur : ce qui marche vraiment contre le piratage
Vous n'êtes pas développeur, et vous voulez juste protéger votre téléphone. Bonne nouvelle : trois réglages font l'essentiel, et aucun antivirus gratuit ne remplace ça.
Comment sécuriser mon téléphone Android (ou Samsung)
Sur Android, activez d'abord Google Play Protect si ce n'est pas déjà fait : il scanne les apps installées et détecte les comportements anormaux. Ensuite, vérifiez les autorisations des apps une par une, dans les réglages. Une app de lampe torche qui demande l'accès aux contacts, c'est un signal. Enfin, refusez d'installer des APK hors du Play Store sans raison solide : c'est par là que passe la majorité des logiciels malveillants.
Sur Samsung, la surcouche ajoute Samsung Knox, un espace sécurisé matériel qui chiffre les données sensibles. Ça ne remplace pas la prudence, mais ça complique sérieusement la tâche d'un attaquant sur un appareil non rooté.
Comment protéger son iPhone contre le piratage
iOS est plus fermé, mais pas invulnérable. Le vecteur principal reste le phishing : un site qui imite iCloud et vous demande votre mot de passe Apple. Activez l'authentification à deux facteurs sur votre identifiant Apple, c'est le geste à plus fort impact. Vérifiez aussi que Verrouillage de l'activation est bien actif : sans votre identifiant, un iPhone volé est inutilisable, ce qui retire tout intérêt au vol.
Les antivirus gratuits servent-ils à quelque chose ?
Franchement, peu. Sur iOS, ils sont presque inutiles tant le système est cloisonné. Sur Android, ils font surtout ce que Play Protect fait déjà, avec de la publicité en plus. Ce qui protège réellement, c'est votre comportement : ne pas cliquer sur un lien douteux, ne pas installer n'importe quoi, garder le système à jour. Un antivirus gratuit peut servir de filet de sécurité quand on installe beaucoup d'apps, mais il ne remplace jamais la vigilance.
Ce qui reste après avoir tout fermé
Même avec les huit failles bouchées, un appareil rooté reste un appareil compromis. Un utilisateur qui installe n'importe quoi finit par installer quelque chose de mauvais. Et un attaquant patient attendra la prochaine dépendance vulnérable pour frapper.
Ce que j'ai fini par comprendre, c'est que la sécurité mobile n'est jamais un état atteint. C'est un rythme. Celui qui met à jour ses dépendances tous les mois, qui chiffre ses données, qui ne laisse aucun secret dans son code, aura toujours un train d'avance sur celui qui attend l'audit annuel. Ce n'est pas glorieux. Et c'est exactement ce qui marche.
