Sécurité des applications mobiles : ce qu'il faut savoir avant de faire confiance à une app
Une question revient sans arrêt quand on parle sécurité mobile : « mais concrètement, comment je sais si une app est dangereuse ? » Franchement, la réponse honnête, c'est que vous ne le savez pas — pas à l'œil nu. Une app peut afficher cinq étoiles sur le store, avoir une interface impeccable, et transmettre vos identifiants en clair à un serveur mal configuré. J'ai vu exactement ce scénario sur un projet qu'on m'avait demandé d'auditer, et personne dans l'équipe ne s'en était rendu compte pendant onze mois.
Ce qui m'agace, c'est que la plupart des articles sur le sujet vous expliquent qu'il faut « mettre à jour vos applications » et « éviter le Wi-Fi public ». Merci, on avait compris. Le vrai problème est ailleurs, et il tient en une phrase : la sécurité d'une app mobile ne se joue presque jamais sur votre téléphone, elle se joue chez celui qui l'a codée.
Points clés à retenir
- La majorité des failles mobiles viennent du stockage local non protégé et des API mal sécurisées, pas de votre usage.
- Le RGPD impose des obligations précises à l'éditeur : minimisation, durée de conservation, registre, et des sanctions qui peuvent atteindre plusieurs millions d'euros.
- Les référentiels OWASP MASVS et le guide de sécurité des API de l'ANSSI donnent une grille de lecture concrète pour évaluer un éditeur.
- Un audit mobile sérieux combine analyse statique et dynamique — un simple scan automatique ne prouve rien.
- iOS et Android n'ont pas les mêmes surfaces d'attaque : le sandboxing d'iOS limite beaucoup de dégâts qu'Android laisse passer.
Où se joue réellement la sécurité d'une application mobile
Quand on parle de sécurité des données personnelles, on imagine souvent un hacker dans un sous-sol. La réalité est plus banale et plus dérangeante.
Le stockage local : le premier coupable, et de loin
Sur une app que j'ai testée, le jeton d'authentification de l'utilisateur était écrit en clair dans un fichier de préférences. N'importe qui avec un accès physique au téléphone — pas besoin d'être un génie — pouvait le récupérer en branchant l'appareil à un ordinateur. Ce n'est pas un cas isolé. Dans mon expérience, c'est la faille numéro un sur les apps qu'on me demande d'évaluer, devant les problèmes de permissions et loin devant le chiffrement du transport.
La raison est presque toujours la même : la personne qui a codé voulait aller vite. Le stockage sécurisé (Keychain sur iOS, Keystore sur Android) demande quelques lignes de plus. Ces quelques lignes, on les saute quand la deadline approche.
Les API : le point où tout se joue vraiment
Voilà le vrai sujet, et celui dont personne ne parle assez. Une app mobile n'est qu'une coquille. Tout ce qui compte — vos données, vos paiements, votre profil — transite par des API. Si ces API sont mal sécurisées, peu importe que l'app soit belle et que votre téléphone soit à jour.
Le guide de sécurité des API de l'ANSSI est d'ailleurs très clair sur un point qu'on oublie systématiquement : l'authentification ne suffit pas, il faut de l'autorisation fine, requête par requête. J'ai vu une API où l'authentification était parfaite — mais où n'importe quel utilisateur connecté pouvait demander les données d'un autre utilisateur en changeant juste un identifiant dans l'URL. Ce type de faille porte un nom, on l'appelle un défaut de contrôle d'accès, et c'est ce que je trouve le plus souvent en audit.
Le problème ? Les équipes sécurisent l'entrée de l'immeuble et laissent toutes les portes internes ouvertes.
iOS et Android : deux mondes, deux niveaux de risque
On présente souvent les deux systèmes comme équivalents. C'est faux, et la différence change votre exposition réelle.
Android laisse davantage de marge aux développeurs — donc davantage d'occasions de se tromper. Le sideloading, l'accès plus large au système de fichiers, la fragmentation des versions : tout cela élargit la surface d'attaque. iOS impose un sandboxing strict entre applications, ce qui limite mécaniquement les dégâts. Une app mal codée sur iOS aura du mal à lire les données d'une autre app. Sur Android, c'est moins vrai.
| Critère | iOS | Android |
|---|---|---|
| Isolation entre apps | Très stricte (sandbox) | Variable selon la version |
| Installation hors store | Très encadrée | Courante |
| Fragmentation des versions | Faible | Élevée |
| Contrôle de la revue de store | Historiquement plus strict | Plus permissif |
| Stockage sécurisé natif | Keychain | Keystore |
Cela ne veut pas dire qu'iOS est sûr. Une app iOS peut parfaitement envoyer vos données n'importe où. Simplement, si elle est compromise, les dégâts restent plus souvent confinés à cette app-là.
Ce que la loi impose à l'éditeur (et ce que vous pouvez exiger)
Ici, beaucoup d'éditeurs racontent n'importe quoi. Le RGPD n'est pas une recommandation, c'est une obligation, et ses exigences sont précises.
- Minimisation : ne collecter que ce qui est strictement nécessaire au service.
- Durée de conservation : définir et respecter une limite, pas garder indéfiniment « au cas où ».
- Registre des traitements : documenter quelles données sont traitées, pourquoi, et par qui.
- Information de l'utilisateur : une politique de confidentialité lisible, pas un pavé juridique de quarante pages.
- DPO : un délégué à la protection des données dès que le traitement est sensible ou à grande échelle.
Les sanctions, elles, ne sont pas symboliques. La CNIL peut prononcer des amendes qui se chiffrent en millions d'euros pour les manquements graves. Je ne vais pas vous citer un montant précis sorti de nulle part — mais retenez l'ordre de grandeur : pour une entreprise, une seule sanction peut coûter plus cher que tout son budget de développement.
Ce que vous, utilisateur, pouvez exiger : une politique de confidentialité qui explique vraiment ce qui est collecté. Une app qui réclame l'accès à vos contacts pour une fonction qui n'en a aucun besoin est un signal. Pas une preuve, un signal.
Comment évaluer le niveau de sécurité d'une app sans être expert
Vous n'êtes pas développeur, et vous voulez quand même savoir si l'app que vous installez tient la route. Voici ce que je conseille, dans l'ordre.
Le contrôle des autorisations, à faire une fois pour toutes
Allez dans les réglages de votre téléphone, section vie privée, et regardez ce que chaque app demande. Une app de recettes qui veut accéder à votre position en arrière-plan ? Ce n'est pas normal. Révoquez, tout simplement.
Les signaux qui trahissent un éditeur sérieux
Un éditeur qui prend la sécurité au sérieux publie une politique de confidentialité claire, explique où sont hébergées vos données, et répond aux questions. S'il botte en touche dès qu'on demande des précisions techniques, c'est mauvais signe. Un audit mobile sérieux repose sur deux approches complémentaires : l'analyse statique (lire le code sans l'exécuter) et l'analyse dynamique (observer le comportement de l'app pendant qu'elle tourne). Les outils existent — MobSF pour l'analyse automatisée, Frida pour l'instrumentation dynamique. Un éditeur qui connaît ces noms, c'est plutôt bon signe. Celui qui n'a jamais entendu parler d'analyse dynamique, beaucoup moins.
Le chiffrement du transport, le minimum vital
Toute communication entre l'app et son serveur doit passer par HTTPS, avec une vérification stricte du certificat. Une app qui vous laisse vous connecter sur un réseau non chiffré expose vos identifiants. C'est le minimum, et c'est encore trop souvent absent sur des apps anciennes jamais mises à jour.
Pour aller plus loin, le référentiel OWASP MASVS et le guide de l'ANSSI sur la sécurisation des API constituent une grille de lecture fiable. Ce ne sont pas des documents marketing, ce sont des exigences vérifiables.
L'erreur que je vois partout, y compris chez des équipes expérimentées
La sécurité traitée comme une case à cocher en fin de projet.
Une équipe passe quatre mois à développer, puis ajoute une semaine d'« audit » juste avant la mise en production. Sauf qu'à ce stade, les choix d'architecture sont figés. Si le stockage des données a été mal pensé au départ, vous ne rattrapez pas ça en une semaine. Il faut tout refaire — et personne ne veut tout refaire à trois jours du lancement.
La bonne approche, et je le dis franchement, c'est d'intégrer les contraintes de sécurité dès les premières discussions d'architecture. C'est moins spectaculaire, mais c'est la seule méthode qui marche. J'ai vu une équipe reprendre entièrement sa couche d'authentification après un audit tardif : six semaines de retard, pour un problème qui aurait coûté deux jours s'il avait été traité au début.
Et si vous êtes du côté éditeur, gardez une chose en tête : vos utilisateurs vous confient leurs données, souvent sans comprendre ce qu'ils font. Cette confiance se perd une seule fois.
La vraie question n'est peut-être pas « cette app est-elle sécurisée », mais « combien de temps l'éditeur mettra-t-il à réagir quand une faille sera découverte ». Les apps parfaites n'existent pas. Celles qui répondent vite, en revanche, existent — et ce sont celles-là dont je garde l'installation sur mon téléphone.