Une app qui plante au lancement, ça se voit tout de suite. Une app qui fuit les données de ses utilisateurs, ça peut mettre des mois avant de se savoir. Et quand ça arrive, la facture ne ressemble pas à un bug : elle ressemble à une notification de violation de données envoyée à la CNIL, à des avis à une étoile qui s'accumulent, et à un compte développeur suspendu.
La question « comment sécuriser une application mobile avant publication » revient à chaque fois que je discute avec une équipe qui s'apprête à soumettre un build. Presque toujours, la même réponse : « on a le HTTPS et un mot de passe, ça devrait aller ». Et presque toujours, le vrai problème est ailleurs — dans un SDK analytics ajouté six mois plus tôt que personne n'a relu, ou dans un fichier de config laissé en dur dans le dépôt.
Voici comment je cadre cette phase désormais. Pas une liste de bonnes intentions : un passage en revue avec des critères de décision, ceux qui servent à dire « on publie » ou « on repousse d'une semaine ».
Points clés à retenir
- La sécurité avant publication, c'est un gate, pas une case à cocher : sans critère de sévérité défini, aucune décision n'est possible.
- Le stockage local sur le téléphone est le premier angle mort : tout ce qui est écrit en clair dans le sandbox de l'app est lisible sur un appareil rooté ou jailbreaké.
- Les échanges réseau se sécurisent aujourd'hui plus mal qu'il y a cinq ans, à cause de l'empilement de SDK tiers.
- Les stores imposent des formulaires et des mécanismes de déclaration qui vous forcent à savoir ce que votre app collecte réellement.
- Un audit de dépendances prend une demi-journée et attrape souvent plus de choses qu'un test d'intrusion complet.
Sécuriser une application mobile avant publication : par où commencer (et surtout par où ne pas commencer)
Le réflexe naturel est de commander un pentest. Mauvaise entrée en matière dans la majorité des cas. Un test d'intrusion sur une app qui stocke encore son token d'API en clair dans les préférences partagées, c'est payer quelqu'un pour vous dire ce qu'une recherche de cinq minutes dans le code aurait révélé.
L'ordre qui fonctionne, dans mon expérience, va du moins cher au plus cher :
- Cartographier les flux de données — quelles données personnelles entrent, où elles sont stockées, où elles sortent. Une heure sur un tableau blanc.
- Auditer les dépendances — SDK tiers, bibliothèques obsolètes, versions avec CVE connues.
- Traquer les secrets dans le dépôt — clés d'API, identifiants de backend, endpoints internes.
- Vérifier le stockage et le transport avant de toucher à l'authentification.
- Seulement ensuite, test d'intrusion et revue de code ciblée.
Ce séquencement m'a fait gagner un temps considérable sur un projet de mise en relation entre particuliers. On avait budgété un pentest externe. Le point 2 a remonté un SDK publicitaire abandonné depuis dix-huit mois, avec une version de bibliothèque réseau vulnérable. On l'a retiré, le pentest a coûté un tiers du devis initial parce qu'il n'a pas eu à chercher dans cette direction.
Pourquoi verrouiller une application ?
Verrouiller une application, c'est limiter ce que quelqu'un peut en faire une fois qu'elle est entre ses mains — y compris un utilisateur légitime avec un appareil compromis. La raison est simple : un téléphone perdu ou volé, c'est un appareil qui contient déjà une session ouverte, parfois un jeton de rafraîchissement valide des semaines.
Trois raisons concrètes, dans l'ordre d'importance que je leur donne :
- Un accès physique à un appareil déverrouillé donne accès à tout ce que l'app a stocké sans protection supplémentaire.
- Les stores durcissent leurs exigences de déclaration, et une app qui ne sait pas ce qu'elle collecte se fait recaler en review.
- La réputation. Une fuite rendue publique coûte plus cher que n'importe quelle mesure préventive — et sur une app grand public, la notification aux utilisateurs est obligatoire en cas de violation de données personnelles.
Ce n'est pas une question de paranoïa. C'est une question de surface d'attaque : chaque fonctionnalité ajoutée en ouvre une, et le verrouillage applicatif réduit ce que l'attaquant peut atteindre depuis l'app.
Le stockage local : le premier endroit où les données fuient
Sur un appareil rooté ou jailbreaké, le bac à sable de l'application n'est plus une barrière. Tout ce que vous écrivez sur le disque peut être lu. Et ce n'est pas une menace théorique : sur les Android d'entrée de gamme un peu anciens, les outils de root sont accessibles, et une partie non négligeable des utilisateurs en installe.
Ce qui doit être chiffré, à mon sens, sans exception : jetons d'authentification, données de santé, coordonnées de paiement, données de localisation précises, identifiants d'utilisateur. Le reste peut souvent rester en clair — chiffrer des préférences d'affichage n'apporte rien et complique la maintenance.
Concrètement, où stocker quoi
Les plateformes fournissent des coffres dédiés, et c'est là qu'il faut aller avant d'écrire une ligne de code de chiffrement maison. Sur iOS, le Keychain. Sur Android, le Keystore, avec la bibliothèque de chiffrement recommandée par la plateforme pour envelopper les données.
Un piège classique, et j'y suis tombé : chiffrer une valeur mais laisser la clé de chiffrement en dur dans le code de l'app. Autant ne rien chiffrer. Une clé embarquée dans le binaire est extractible en quelques minutes par analyse statique. La clé doit venir du keystore de la plateforme, jamais d'une constante dans le dépôt.
Autre point souvent oublié : les sauvegardes automatiques. Sur Android, le backup système peut copier vos fichiers de données vers le cloud. Il faut explicitement exclure les fichiers sensibles de la sauvegarde, sinon votre chiffrement local ne protège rien en cas de restauration sur un autre appareil.
Résultat à retenir : un stockage non protégé rend inutile tout le reste de votre dispositif.
Comment protéger une application : les flux réseau et l'authentification
Ici, l'ennemi n'est pas l'attaquant qui casse du chiffrement. C'est vous, dans six mois, qui ajoutez une bibliothèque d'analyse d'audience sans vérifier ce qu'elle envoie. J'ai vu une app de suivi sportif transmettre des données de santé à un SDK publicitaire tiers, non pas par décision, mais parce que quelqu'un avait copié-collé une initialisation d'un tutoriel.
Comment activer la protection des applications ?
La protection ne s'« active » pas d'un coup dans un menu. Elle se construit par couches, et chaque couche correspond à un mécanisme que la plateforme met à disposition. Ce qui se règle concrètement :
- Le chiffrement en transit : TLS partout, y compris pour les appels internes, avec les certificats correctement épinglés si votre écosystème le justifie.
- La vérification d'intégrité : sur Android, Play Integrity ; sur iOS, App Attest. Cela permet à votre backend de refuser une requête qui ne vient pas d'une version authentique de l'app.
- Le refus de tourner sur appareil compromis : détection de root/jailbreak, à discuter selon le contexte (sur une app bancaire, oui ; sur un jeu, c'est probablement disproportionné).
- L'expiration des sessions : jetons courts, rafraîchissement contrôlé, révocation possible côté serveur.
- La protection contre les captures et overlays sur les écrans qui affichent des données sensibles.
Le vrai piège technique : ces mécanismes doivent être vérifiés côté serveur. Activer Play Integrity dans l'app mais accepter n'importe quel jeton côté backend, c'est décorer un mur qui n'existe pas.
| Couche | Objectif | Effort typique | Gain réel |
|---|---|---|---|
| Stockage chiffré | Protéger les données au repos | Faible à moyen | Très élevé |
| TLS + épinglage | Protéger les échanges | Faible | Élevé |
| Vérification d'intégrité | Bloquer les clients falsifiés | Moyen | Moyen |
| Détection root/jailbreak | Limiter l'usage sur appareil compromis | Moyen | Variable |
| Pentest complet | Découvrir ce que vous ignorez | Élevé | Élevé si le reste est fait |
Avant la soumission : ce que les stores vont réellement vérifier
Il y a un angle que presque personne ne mentionne dans les guides de sécurité mobile, et c'est pourtant celui qui bloque le plus de publications : les formulaires de déclaration. Google Play demande une déclaration de sécurité des données ; Apple demande une déclaration de confidentialité et un manifeste de confidentialité listant les API sensibles utilisées par l'app et par ses SDK.
Le problème ? Ces formulaires vous obligent à connaître précisément ce que chaque dépendance collecte. Et si vous ne le savez pas, vous allez mentir sans le vouloir — ce qui est bien plus grave qu'une faille technique, parce que c'est vérifiable et sanctionnable.
Dans mon expérience, remplir correctement la déclaration de sécurité des données prend une à deux journées de travail sérieux sur une app de taille moyenne. Pas parce que le formulaire est complexe, mais parce qu'il faut ouvrir chaque SDK et vérifier ses pratiques.
La vérification go / no-go
Le critère de décision doit être posé avant la revue, pas après. Voici celui que j'utilise :
- Aucune vulnérabilité critique ou élevée non corrigée dans les dépendances.
- Aucun secret en dur dans le dépôt (scan automatisé en CI).
- Stockage sensible chiffré avec des clés issues du keystore.
- Déclaration de confidentialité cohérente avec le comportement réel observé (test en environnement instrumenté).
- Signature de code en place, build de production distinct du build de développement.
- Obfuscation activée sur la release, mappings conservés pour la lecture des rapports de crash.
Un seul point en rouge, et on repousse. C'est arbitraire ? Peut-être. Mais j'ai vu trop de « on publie quand même, on corrigera dans la mise à jour » se transformer en trois semaines de panique quand la mise à jour en question n'est jamais arrivée.
Trois choses que j'ai vues échouer (et qu'on croise partout)
Chiffrer avec une bibliothèque maison. Ça marche jusqu'au jour où personne ne se souvient de l'algorithme, et où un changement de plateforme casse tout. Les primitives fournies par le système font le travail, avec des gens dont le métier est de les auditer.
Considérer le pentest comme une case à cocher. Un rapport de pentest daté d'il y a huit mois sur un code qui a changé trois fois depuis ne vaut pas grand-chose. Le test doit être rejoué à chaque évolution significative de l'authentification ou des flux de données.
Oublier l'après. La sécurité avant publication n'est qu'un instant. Le jour suivant, une nouvelle CVE sort sur une bibliothèque que vous utilisez. Sans veille automatisée sur les dépendances, vous serez vulnérable en silence pendant des mois.
Le verrouillage d'une application ne se termine pas le jour de la mise en ligne. C'est une posture qui se maintient — ou qui s'effondre sans bruit.
Et si vous devez ne retenir qu'une chose : commencez par la cartographie des données et l'audit des dépendances. Une journée de travail, deux personnes, un tableur. C'est rarement le plus excitant. C'est presque toujours là que se trouve ce qui vous aurait coûté le plus cher.
