Sécurité des applications mobiles : ce qu'il faut savoir pour protéger vos données

Un développeur freelance m'a appelé un mardi soir, paniqué. Son app de réservation de salles de sport comptait 40 000 utilisateurs. La veille, quelqu'un avait trouvé la clé d'API qu'il avait laissée en dur dans le code. Résultat : 12 000 comptes clients aspirés en une nuit, avec noms, adresses et historiques de paiement. Il a mis onze jours à s'en rendre compte. La sécurité des applications mobiles, ce n'est pas une case à cocher avant la mise en ligne. C'est ce qui sépare une app qui vit d'une app qui finit en une du journal local.

La sécurité des applications mobiles : où se joue vraiment la bataille

Quand on parle de sécurité mobile, tout le monde imagine un hacker dans le noir qui craque un chiffrement militaire. La réalité est plus embarrassante. Dans mon expérience, 9 failles sur 10 que j'ai croisées sur des apps en production relevaient de trois négligences : un secret exposé, une API qui fait confiance à n'importe qui, ou un stockage local en clair.

Le problème de fond, c'est que l'app mobile vit sur un appareil que vous ne contrôlez pas. Vous ne savez pas si l'utilisateur a rooté son téléphone, s'il utilise un vieux système sans correctifs, ou s'il a installé une version modifiée de votre app. Le sandbox protège partiellement, mais il ne fait pas le travail à votre place.

Le vrai champ de bataille est côté serveur, pas côté app

Voilà ce qui m'a pris deux ans à comprendre, et qui aurait dû m'être enseigné dès le premier jour. Le code d'une app mobile, on peut le décompiler. Il est chez l'utilisateur. Donc aucune logique sensible ne doit y vivre. Les clés, les règles de validation, les décisions d'autorisation : tout ça appartient au serveur.

Une app bien faite peut être entièrement décompilée sans que l'attaquant y trouve quoi que ce soit d'exploitable. Une app mal faite contient l'équivalent du plan de la banque affiché sur la porte d'entrée.

Concrètement, ce que je vérifie systématiquement côté back :

• Aucune clé d'API secrète dans le code ou les ressources de l'app (fichiers de config, strings.xml, Info.plist)
• Chaque endpoint authentifie l'utilisateur et vérifie ses droits sur la ressource demandée, pas seulement son identité
• Limitation de débit contre le bourrage d'identifiants et le scraping
• Validation stricte des entrées, même si l'app côté client valide déjà
• Journalisation des accès côté serveur, pas côté client

Le point numéro 2 est celui qui plante le plus de projets. Je l'ai vu sur une app de gestion locative : l'API vérifiait bien que vous étiez connecté, mais pas que le logement demandé vous appartenait. Il suffisait de changer un numéro dans la requête pour lire les dossiers de tout le monde. Négligence, pas génie.

iOS et Android ne présentent pas les mêmes risques

On lit partout qu'Android est « moins sûr » que iOS. C'est trop simple, et ça cache l'essentiel. Sur Android, la fragmentation des versions est le vrai problème : une part importante des appareils tourne encore sur des versions qui ne reçoivent plus de correctifs. Sur iOS, la contrainte est inverse : les mises à jour arrivent vite et largement, mais le système impose ses règles de chiffrement et de stockage.

Pour le développeur, ça se traduit dans le code :

Point	iOS	Android
Stockage sécurisé natif	Keychain	Keystore + EncryptedSharedPreferences
Chiffrement à la compilation	Peu accessible au développeur	Obfuscation possible (R8/ProGuard)
Fonctionnement sur appareil rooté	Détection possible, moins courante	Fréquent, à traiter comme un cas normal
Sideloading hors boutique	Très limité	Courant selon les régions
Permissions sensibles	Demande explicite par usage	Historiquement plus larges

Ma règle : je conçois pour Android, puis j'ajoute les garde-fous iOS. Ceux qui font l'inverse se retrouvent à découvrir, en production, que leur stockage « sécurisé » n'a jamais été activé.

Les risques concrets qu'une application mobile affronte

La liste des dangers est longue, mais elle se réduit à un petit nombre de scénarios qui reviennent sans cesse. Les nommer, c'est déjà la moitié du travail.

L'API : le maillon faible numéro un

Vous avez sûrement vu passer les recommandations de l'ANSSI sur la sécurisation des API. C'est du solide, et ce n'est pas un hasard si le sujet revient partout. Une API d'app mobile est exposée, documentée (parfois à son insu), et souvent mal protégée. Trois erreurs que je rencontre chaque année :

1. Une authentification par simple clé d'API, qui n'identifie pas l'utilisateur mais l'app, et qui se partage donc sans limite
2. Des réponses d'API qui renvoient plus de champs que nécessaire (le overfetching, qui expose des données internes)
3. Absence de séparation entre les environnements de test et de production, avec parfois les mêmes identifiants

Sur une mission récente, une API répondait à une requête GET avec le hash du mot de passe de l'utilisateur dans la réponse. Inutile pour l'app, précieux pour un attaquant qui réutilise le hash ailleurs. Correction : 4 lignes de code. Détection : 3 semaines de tests.

Le stockage local : le piège silencieux

Une app sur cinq que j'ai auditées écrivait des données sensibles dans le système de fichiers sans chiffrement, ou pire, dans des bases de données accessibles depuis d'autres applications sur l'appareil. Le token de session, le plus souvent. Et un token de session non chiffré, c'est une session utilisateur volée qui attend.

La règle est simple : si une donnée ne doit pas apparaître dans une capture d'écran, elle ne doit pas atterrir en clair sur le disque.

Le guide de la sécurité des données personnelles appliqué au mobile

Le RGPD n'est pas un texte abstrait. Il impose des obligations qui se traduisent dans le code, ligne par ligne. Ce que la CNIL appelle la protection dès la conception, c'est refuser de collecter une donnée parce qu'« on ne sait jamais, ça pourrait servir ».

Minimisation et durées de conservation, en pratique

Je pose toujours la même question au client avant de toucher à une app : « cette donnée, vous en faites quoi si je vous la retire ? ». Si la réponse est floue, elle ne doit pas être collectée. Chaque champ stocké est un champ qui peut fuir.

Sur les durées de conservation, le principe est qu'une donnée ne se garde pas indéfiniment. Les journaux de connexion, par exemple, se gardent le temps strictement nécessaire à la sécurité, pas dix ans. Ce que j'ai vu de plus aberrant : des apps qui conservaient l'historique de géolocalisation complète depuis la première installation, sans jamais purger.

Évaluer le niveau de sécurité des données personnelles de votre organisme

Avant de parler de référentiels, il faut pouvoir répondre à une question simple : où sont vos données, qui y accède, et avec quel niveau de preuve ? Dans mon expérience, les organisations qui échouent à un audit ne manquent pas d'outils ni de budget. Elles manquent d'une cartographie honnête de leurs flux.

Un exercice utile : prenez une donnée utilisateur (une adresse email, par exemple), et suivez-la de son entrée dans l'app jusqu'à sa suppression. Combien d'intermédiaires la voient ? Combien la stockent ? Combien la transmettent à un service tiers non prévu au départ ? Vous serez surpris. Sur un projet, ce simple traçage a révélé que les données passaient par un outil d'analytics que personne n'avait configuré — et qui n'apparaissait dans aucun registre.

Comment évaluer la sécurité d'une app mobile sans se ruiner

Pas besoin d'un pentest à 40 000 euros pour commencer. Trois actions gratuites ou presque détectent l'écrasante majorité des problèmes réels.

Les premiers tests à faire vous-même

• Décompiler l'APK ou l'IPA et chercher les chaînes de caractères qui ressemblent à des clés, des tokens, des URLs internes
• Intercepter le trafic réseau (Burp, mitmproxy) et observer ce qui circule en clair
• Lire les permissions déclarées dans le manifeste : y en a-t-il qui ne servent à rien ?
• Vérifier la validation des entrées côté serveur, jamais seulement côté client

Sur un audit d'une petite app de messagerie, ces quatre points ont suffi à révéler que les messages transitaient en HTTP simple, sans chiffrement. La version « sécurisée » était prévue pour plus tard. Le « plus tard » n'est jamais arrivé.

OWASP MASVS, ANSSI, ISO 27001 : quand aller plus loin

Pour un projet sérieux, le référentiel OWASP MASVS reste la base la plus accessible. Il liste les exigences de sécurité mobile par niveau, et sert de grille de lecture honnête. L'ANSSI publie de son côté des recommandations utiles, notamment sur les API. ISO 27001 relève d'une démarche d'entreprise plus large, pas d'un audit d'app isolé.

Mon conseil personnel : commencez par MASVS, mesurez l'écart, puis décidez si vous visez l'audit formel. Beaucoup de projets corrigent 80 % du risque avec 20 % de l'effort, uniquement en appliquant les niveaux 1 et 2 du référentiel.

Ce qui reste une fois qu'on a tout corrigé

La sécurité mobile parfaite n'existe pas. Le jour où vous aurez tout corrigé, un nouveau correctif système sortira, une nouvelle version de l'app apparaîtra, une nouvelle dépendance introduira une faille. Le travail n'est jamais terminé, et c'est normal.

Ce qui compte, c'est la posture. Une app qui continue de se faire tester, qui met à jour ses dépendances, qui ne stocke pas ce dont elle n'a pas besoin, survivra. Une app qui a passé un audit unique il y a deux ans et qu'on n'a pas rouverte depuis est probablement déjà vulnérable quelque part. Le développeur que j'ai mentionné au début a fini par tout reprendre. Sa nouvelle version compte moins d'utilisateurs, mais elle ne contient plus aucun secret dans le code. C'est un progrès qu'on ne mesure pas sur un tableau de bord.

Posez-vous une question simple ce soir : si je décompilais mon app demain matin, qu'est-ce que j'y trouverais ?