La question qui revient le plus souvent quand je discute avec des équipes produit, ce n'est pas « comment on sécurise une app mobile ? » mais « par où on commence ? ». Et c'est précisément là que les choses dérapent : on empile des outils, on coche des cases dans un tableur, et six mois plus tard on découvre qu'un jeton d'API traînait en clair dans les logs depuis le lancement.
J'ai vu ce scénario trois fois sur des projets différents. À chaque fois, le problème n'était pas technique au départ. Il était organisationnel.
Points clés à retenir
- La sécurité d'une app mobile se joue à quatre endroits distincts : le code embarqué, le stockage local, les échanges réseau, et le back-end.
- Un secret qui se trouve dans le binaire de l'app n'est jamais un secret. Point.
- La surface d'attaque d'une API mobile est plus large que celle d'un site web, parce que le client est entre les mains de l'utilisateur.
- Le chiffrement au repos ne sert à rien si les clés sont stockées à côté des données.
- Une politique de sécurité qui n'est pas testée en conditions réelles est une politique décorative.
- Les obligations de conformité (RGPD, et selon votre secteur, des exigences sectorielles) vous imposent de documenter ce que vous collectez et pourquoi.
Sécurité des applications mobiles : les points clés qu'on oublie systématiquement
Un chiffre d'abord. Sur une trentaine d'apps que j'ai auditées ou vues auditer ces dernières années, la grande majorité exposait au moins une clé d'API en clair dans son code compilé. Pas une faille exotique. Une clé AWS, une clé Stripe, parfois un jeton d'administration back-office.
Pourquoi ? Parce qu'un développeur presse a besoin de cette clé pour faire fonctionner le prototype. Et le prototype devient la production. Vous connaissez la suite.
Pourquoi le code mobile est particulièrement exposé
Contrairement à un serveur que vous contrôlez, une app mobile s'exécute sur un appareil que vous ne contrôlez pas. L'utilisateur peut la décompiler, la modifier, l'instrumenter. Un APK, c'est un fichier zip. On le dézippe, on le passe dans un décompilateur, et on lit le Java.
Ce que ça implique concrètement :
- Obfuscation : elle ralentit l'analyse, elle ne l'empêche pas. Si vous comptez uniquement là-dessus, vous vous racontez une histoire.
- Les chaînes de caractères en dur — URLs, clés, identifiants — restent lisibles même après obfuscation.
- La détection de root ou de jailbreak vaut ce qu'elle vaut : elle se contourne, mais elle filtre les attaquants opportunistes.
- L'attestation d'intégrité (Play Integrity, App Attest) est aujourd'hui la seule barrière vraiment solide contre un client modifié. Elle aussi se contourne sur appareil rooté, mais elle augmente sérieusement le coût de l'attaque.
Ma règle personnelle : rien de sensible ne doit vivre côté client. Si votre app a besoin d'un secret pour fonctionner, ce secret doit transiter par votre back-end, jamais être embarqué.
Stockage local : le point où tout le monde se fait prendre
Il y a deux ans, une équipe m'a montré une app de suivi médical plutôt bien faite. Chiffrement des échanges, authentification à deux facteurs, API propre. Sauf que les notes de santé étaient stockées en clair dans une base SQLite accessible via un backup ADB.
Le correctif a pris deux jours. La honte, elle, est restée plus longtemps.
Sur iOS, vous avez le Keychain. Sur Android, l'EncryptedSharedPreferences ou le Keystore matériel. Ces mécanismes existent depuis des années et restent sous-utilisés. Le réflexe à avoir : toute donnée qui identifie une personne ou qui pourrait lui nuire si elle fuit ne doit jamais atterrir sur le système de fichiers brut.
Sécurité API mobile : la zone la plus sous-estimée
Le back-end qui alimente une app mobile est une API publique. Vous pouvez la trouver, la tester, l'attaquer. Il n'y a pas de « mais elle est cachée derrière l'app ». N'importe qui avec un proxy intercepte vos requêtes.
Ce que j'observe le plus souvent :
- Des endpoints qui ne vérifient pas si l'utilisateur a le droit d'accéder à la ressource demandée. On change un identifiant dans l'URL et on récupère les données d'un autre.
- Aucune limitation de débit. Un script peut tester 50 000 combinaisons d'identifiants en une nuit.
- Des jetons d'authentification valables six mois, sans révocation possible.
Faut-il épingler les certificats (certificate pinning) ?
Oui, avec des précautions. Le pinning empêche une attaque par interposition quand l'utilisateur a installé un certificat racine douteux. Mais — et c'est le piège classique — si vous épinglez votre certificat de production et que vous oubliez de prévoir la rotation, votre app devient inutilisable le jour où le certificat expire.
J'ai vu cette erreur coûter une journée entière d'indisponibilité à un client. La leçon : épinglez toujours la clé publique, pas le certificat, et prévoyez au moins deux empreintes en parallèle pour permettre une rotation sans mise à jour forcée.
Les points à vérifier côté API
| Contrôle | Ce que ça bloque | Effort |
|---|---|---|
| Autorisation par ressource | Accès horizontal aux données d'un autre utilisateur | Moyen |
| Limitation de débit par jeton | Force brute, scraping massif | Faible |
| Rotation et révocation des jetons | Réutilisation d'un jeton volé | Moyen |
| Validation stricte des entrées | Injection, désérialisation malveillante | Faible |
| Journalisation sans données sensibles | Fuite par les logs | Faible |
Le dernier point fait sourire, mais c'est celui qui m'a le plus surpris en audit. Les logs contiennent régulièrement des jetons, des numéros de téléphone, des adresses e-mail. Des équipes qui chiffrent tout le reste balancent les données en clair dans un système de collecte de logs mal protégé.
Sécurité des données personnelles : ce que la conformité vous impose vraiment
La réglementation ne demande pas une technologie précise. Elle demande que vous sachiez quelles données vous collectez, pourquoi, combien de temps, et qui y accède. C'est moins excitant qu'un algorithme, mais c'est là que les sanctions tombent.
Sur le terrain, la minimisation est l'action la plus rentable. Chaque champ que vous ne collectez pas est un champ que vous ne pouvez pas perdre. J'ai vu une app de livraison stocker la date de naissance complète de ses utilisateurs. Pour quoi faire ? Personne ne savait répondre.
Trois questions à poser à chaque nouvelle fonctionnalité :
- Est-ce que cette donnée est nécessaire au service rendu, ou juste « intéressante à avoir » ?
- Combien de temps doit-on la garder, et qui a défini cette durée ?
- Si elle fuit demain, quel est le préjudice pour la personne concernée ?
La CNIL publie des guides qui détaillent ces obligations, et ils sont étonnamment lisibles. L'ANSSI fait de même pour les API. Ce sont des documents longs, mais les lire une fois vaut mieux que de découvrir leurs exigences lors d'un contrôle.
Comment évaluer le niveau de sécurité de votre organisme ?
Commencez par un inventaire honnête. Listez vos apps, les API qu'elles appellent, les données qui circulent, et qui y a accès. La plupart des équipes découvrent à cette étape des flux qu'elles avaient oubliés.
Ensuite, faites tester. Pas un questionnaire rempli en interne, mais un vrai test d'intrusion sur l'API et un test sur le binaire de l'app. Comptez une à deux semaines pour une app de taille moyenne. Le rapport qui en sort est souvent désagréable. C'est le but.
Enfin, mesurez dans le temps. Une app évolue, une API change, une bibliothèque tierce se retrouve avec une vulnérabilité connue. Un audit annuel ne suffit pas si vous livrez toutes les semaines.
Ce que je recommande concrètement, dans l'ordre
Si vous partez de zéro ou presque, voici l'ordre qui a le mieux fonctionné pour moi :
- Inventorier les données et les flux. Sans ça, tout le reste est de la décoration.
- Sortir tous les secrets du code client, sans exception.
- Sécuriser le stockage local avec les mécanismes natifs de la plateforme.
- Reprendre l'autorisation côté API, ressource par ressource.
- Ajouter limitation de débit et révocation des jetons.
- Nettoyer les logs.
- Puis seulement, envisager obfuscation et attestation d'intégrité.
L'ordre compte. J'ai vu des équipes investir dans un outil d'obfuscation coûteux alors que leur API laissait n'importe qui lire les données de n'importe qui. Elles ont protégé la porte d'entrée en laissant le coffre ouvert.
Une dernière chose, et c'est peut-être la plus importante. La sécurité mobile n'est pas un projet qu'on termine. C'est une propriété qui se maintient. Le jour où vous considérez que c'est réglé, c'est généralement le jour où quelque chose commence à pourrir.
Et si vous ne devez retenir qu'une seule phrase de tout ça : traitez votre app comme si elle était déjà entre les mains d'un attaquant. Parce qu'elle l'est probablement.
