Une application mobile place votre produit, et souvent les données les plus personnelles de vos clients, dans des millions de poches que vous ne contrôlez pas. Les téléphones peuvent être perdus, volés, rootés, infectés ou laissés sur des réseaux publics. Des pirates peuvent télécharger votre application, la décrypter et étudier ses communications avec vos serveurs. Dans ce contexte, la sécurité n'est pas une fonctionnalité à ajouter à la fin. Il s'agit d'un ensemble de décisions prises tout au long du projet. La bonne nouvelle, c'est que la plupart des failles de sécurité mobiles ne sont pas rares. Elles proviennent d'une liste restreinte d'erreurs courantes : stockage négligent de données sensibles, confiance excessive accordée à l'application, API backend laissées ouvertes et absence de tests. Cette checklist recense vingt points essentiels à vérifier avant le lancement. Elle est conçue pour permettre aux fondateurs et aux responsables produit de poser les bonnes questions, et aux développeurs de l'utiliser comme aide-mémoire. Pour une planification plus détaillée d'un projet d'application, consultez notre guide des coûts de développement d'applications mobiles et notre page développement d'applications mobiles.
Tout d'abord, l'état d'esprit
Trois principes sous-tendent tout ce qui suit.
- Ne jamais faire confiance au client. Tout ce qui s'exécute sur le téléphone d'un utilisateur peut être inspecté et modifié. Les décisions importantes, telles que les prix, les autorisations et les paiements, doivent être prises sur le serveur.
- Collecter et conserver le moins de données possible. Les données que vous ne stockez jamais ne peuvent pas être volées. Chaque champ que vous collectez représente un risque.
- En cas de faille, limitez les dégâts. Concevez votre système de manière à ce que, si un élément tombe en panne, les dommages soient limités : jetons à durée de vie courte, autorisations limitées, données chiffrées.
Stockage des données sur l'appareil
1. Ne stockez pas de données sensibles sauf en cas d'absolue nécessité.
Les mots de passe, les numéros de carte bancaire complets et les identifiants personnels ne doivent pas être stockés sur l'appareil. Si vous pouvez récupérer des données depuis le serveur en cas de besoin, privilégiez cette méthode plutôt que de les enregistrer localement.
2. Utilisez un stockage sécurisé pour vos données sensibles.
iOS et Android proposent tous deux un stockage protégé pour les informations confidentielles telles que les jetons et les clés : le Trousseau d'accès sur iOS et le Keystore sur Android. Utilisez ces solutions de stockage et non de simples fichiers de préférences, des bases de données locales ou des fichiers texte non protégés. Les frameworks multiplateformes tels que Flutter et React Native offrent des solutions de stockage sécurisé intégrant ces fonctionnalités ; ils devraient être utilisés par défaut pour les jetons et les identifiants.
3. Chiffrez les bases de données locales et les fichiers contenant des données personnelles
Si l'application met en cache les informations utilisateur hors ligne, chiffrez-les. N'oubliez pas que les sauvegardes, les captures d'écran et les journaux peuvent également entraîner des fuites de données ; vérifiez donc où les informations peuvent se retrouver.
4. Supprimez les données sensibles lors de la déconnexion
Lorsqu'un utilisateur se déconnecte, supprimez les jetons, les enregistrements mis en cache et tous les fichiers sensibles. L'utilisation d'appareils partagés ou revendus est fréquente.
Authentification et sessions
5. Utilisez une authentification éprouvée, pas votre propre système
Développer votre propre système de connexion est risqué. Utilisez des normes et des bibliothèques établies, telles que OAuth 2.0 et OpenID Connect, ou un service d'identité réputé. Appliquez des règles de mots de passe raisonnables et protégez-vous contre les tentatives de connexion répétées grâce à des limites de débit et des blocages.
6. Proposez des options de connexion robustes
Prenez en charge l'authentification multifacteur lorsque les données le justifient et utilisez la biométrie de l'appareil, comme la reconnaissance d'empreintes digitales et la reconnaissance faciale, comme une couche de sécurité supplémentaire. La biométrie doit déverrouiller un identifiant stocké en toute sécurité et ne doit pas remplacer les vérifications côté serveur.
7. Limitez la durée des sessions et rendez-les révocables
Utilisez des jetons d'accès à courte durée de vie avec des jetons d'actualisation et permettez de révoquer l'accès en cas de perte de l'appareil. Les jetons à longue durée de vie stockés sans précaution constituent une faille courante.
Communication réseau
8. Utilisez des connexions chiffrées partout
Tout le trafic entre l'application et vos serveurs doit utiliser le protocole TLS moderne. Ne transmettez jamais d'identifiants ni de données personnelles via des connexions non sécurisées et ne négligez pas les erreurs de certificat pendant le développement, ni n'oubliez de réactiver les vérifications lors de la mise en production.
9. Envisagez l'épinglage de certificat pour les applications à haut risque
L'épinglage de certificat oblige l'application à n'accepter que le certificat de votre serveur, ce qui permet de contrer certaines attaques par interception. Cette technique implique une maintenance supplémentaire lors du changement de certificat ; elle est donc plus adaptée aux applications gérant des paiements, des données de santé ou d'autres données hautement sensibles qu'aux simples applications de contenu.
10. N'intégrez pas de secrets dans l'application
Les clés API, les mots de passe et les clés privées intégrés à l'application peuvent être extraits par toute personne la téléchargeant. Tout élément devant rester secret doit être stocké sur votre serveur. Les clés qui doivent impérativement figurer dans l'application, comme celles utilisées pour les cartes, doivent être soumises à des restrictions d'identité et d'utilisation définies par le fournisseur.
Serveur et API
La sécurité de l'application dépend de celle du serveur auquel elle se connecte. Les attaquants contournent souvent complètement l'application et appellent directement votre API.
11. Autoriser chaque requête sur le serveur
Vérifier que l'utilisateur connecté est autorisé à accéder à chaque enregistrement demandé. Une faille courante consiste en un point de terminaison qui renvoie n'importe quelle commande à partir de n'importe quel numéro de commande. Un utilisateur peut donc lire les données d'un autre en modifiant simplement un chiffre dans la requête.
12. Valider toutes les entrées sur le serveur
Ne vous fiez jamais à l'application pour valider les données. Vérifiez les types, les longueurs et les formats sur le serveur et utilisez des requêtes de base de données sécurisées pour empêcher les injections. Les backends construits avec des frameworks matures tels que Laravel offrent par défaut bon nombre de ces protections lorsqu'ils sont utilisés comme prévu ; Nous comparons les options backend dans Laravel vs Node.js.
13. Limitation du débit et surveillance
Limitez la fréquence à laquelle un client peut appeler les points de terminaison sensibles, tels que la connexion, la réinitialisation du mot de passe et les paiements. Enregistrez toute activité inhabituelle et recevez des alertes.
14. Protection adéquate des paiements
Utilisez un prestataire de paiement réputé afin que les informations de carte lui soient directement transmises et ne transitent jamais par vos serveurs. Confirmez les paiements sur le serveur et ne vous fiez jamais à la confirmation de l'application quant à la réussite d'un achat.
L'application elle-même
15. Protection raisonnable du code
Les versions de production doivent être compilées et minifiées, et les fonctionnalités de débogage ainsi que les journaux détaillés doivent être supprimés. L'obfuscation complique la rétro-ingénierie, mais ne la rend jamais impossible. Considérez-la donc comme un obstacle, et non comme une défense, et ne vous y fiez jamais pour protéger vos secrets.
16. Détecter les environnements à risque lorsque cela est important
Pour les applications bancaires, de santé ou autres applications à haut risque, envisagez de vérifier la présence d'appareils rootés ou jailbreakés, de débogueurs et de tentatives de falsification. Ces éléments ajoutent des contraintes et génèrent de fausses alertes ; appliquez-les donc en fonction du risque réel.
17. Demander les autorisations minimales
Ne demandez l'accès à la caméra, à la localisation, aux contacts ou au stockage que lorsque c'est nécessaire, et expliquez pourquoi. Moins d'autorisations signifient une exposition moindre en cas de compromission de l'application et une confiance accrue de la part des utilisateurs.
18. Examiner le code tiers
Les bibliothèques et les SDK s'exécutent avec les autorisations de votre application. Chacun d'eux représente une vulnérabilité potentielle et soulève des questions de confidentialité. Limitez la liste, utilisez des packages bien maintenus, mettez-les à jour régulièrement et examinez les données collectées par les SDK d'analyse ou de publicité.
Processus et préparation
19. Tester la sécurité avant la mise en production
Intégrez la sécurité aux tests, et pas seulement les fonctionnalités.
- Analyses automatisées du code et des dépendances pour détecter les vulnérabilités connues.
- Examen manuel de l'authentification, du stockage et de l'accès à l'API.
- Tests d'intrusion réalisés par un spécialiste indépendant pour les applications traitant des données sensibles.
- Vérifications par rapport à une liste reconnue. Le projet OWASP Mobile Application Security publie des recommandations et des normes de test largement utilisées, une bonne référence pour les analyses.
20. Se préparer aux incidents et aux mises à jour
Décidez à l'avance de ce que vous ferez en cas de problème.
- Un moyen d'obliger les utilisateurs à mettre à jour lorsqu'une faille grave est découverte.
- Surveillance et signalement des plantages pour une détection rapide des problèmes.
- Un contact pour les signalements de sécurité et une procédure pour Réponse.
- Un plan pour informer les utilisateurs et, le cas échéant, les autorités de réglementation.
- Mises à jour régulières pour les systèmes d'exploitation, les bibliothèques et le backend. La sécurité fait l'objet d'un travail continu, comme expliqué dans coûts de maintenance logicielle.
Confidentialité et conformité
La sécurité et la confidentialité se recoupent, mais ne sont pas identiques. La confidentialité concerne les données collectées, leur finalité et le consentement des utilisateurs.
- Ne collectez que les données nécessaires et informez clairement les utilisateurs des données collectées.
- Fournissez une politique de confidentialité qui corresponde à l'activité réelle de l'application.
- Respectez les choix des utilisateurs, tels que les demandes de suppression et les préférences marketing.
- Respectez les règles des plateformes de téléchargement. Apple et Google exigent des informations sur la confidentialité et ont des politiques d'utilisation des données.
- Connaissez vos obligations. Les lois varient selon les pays et les secteurs, par exemple pour les données de santé ou les données relatives aux enfants. Nous vous recommandons de les confirmer auprès d'un conseiller qualifié et de concevoir l'application en conséquence.
Les secteurs sensibles nécessitent une attention particulière. Notre page sur le développement de logiciels de santé décrit les considérations de conception pour les produits liés à la santé.
Tableau de référence rapide
| Domaine | Question clé |
|---|---|
| Stockage | Des données sensibles sont-elles stockées, et le sont-elles dans un stockage sécurisé ? |
| Authentification | Utilisons-nous des normes éprouvées, avec des sessions éphémères et révocables ? |
| Réseau | Tout le trafic est-il chiffré, sans aucune donnée secrète dans l'application ? |
| API | Le serveur autorise-t-il et valide-t-il chaque requête ? |
| Paiements | Les informations de carte sont-elles transmises directement au fournisseur ? |
| Code | Les versions finales sont-elles dépourvues de fonctionnalités de débogage ? |
| Autorisations | Ne demandons-nous que ce dont nous avons besoin ? |
| Dépendances | Les bibliothèques tierces sont-elles peu nombreuses, à jour et vérifiées ? |
| Tests | La sécurité a-t-elle été testée indépendamment ? |
| Réponse | Pouvons-nous forcer les mises à jour et réagir aux incidents ? |
Erreurs courantes
- Intégration en dur des secrets dans l'application.
- Faire confiance au client pour les décisions concernant les prix, les rôles ou l'accès.
- Stocker les jetons dans les préférences en clair.
- Laisser les paramètres de test ou la journalisation de débogage dans la version finale.
- Omettre les contrôles d'autorisation côté serveur.
- Ajouter de nombreux SDK sans vérifier les données qu'ils collectent.
- Considérer la sécurité comme une étape finale plutôt que comme un fil conducteur du projet.
- Absence de mécanisme de mise à jour pour les correctifs urgents.
- Absence de tests avec des attaques réalistes.
- Négliger le backend, où se produisent la plupart des violations graves.
Qui est responsable ?
Tout le monde. Les responsables produit décident des données collectées et du niveau de risque acceptable. Les concepteurs façonnent les flux pour éviter toute exposition inutile. Les développeurs mettent en place des protections. Les testeurs tentent de les contourner. Un bon partenaire de développement soulève ces questions dès le début, et non après le lancement. Lors de votre évaluation, renseignez-vous sur leur approche de la sécurité ; notre guide pour choisir une société de développement logiciel contient des questions permettant d'y répondre.
Conclusion
Il est impossible de rendre une application mobile parfaitement sécurisée, mais vous pouvez en faire une cible difficile et peu rentable, et éviter les erreurs courantes à l'origine de la plupart des violations de sécurité. Stockez moins de données, privilégiez le serveur au téléphone, utilisez une authentification éprouvée, chiffrez le trafic, effectuez des tests rigoureux et prévoyez des solutions de repli.
Si vous envisagez de développer une application et souhaitez intégrer la sécurité dès la conception, contactez-nous. Nous analyserons vos besoins, identifierons les risques importants pour votre produit et intégrerons les protections dès le départ, et non les ajouterons a posteriori.