Sécurité application mobile : guide complet OWASP, RGPD et bonnes pratiques

OWASP Mobile Top 10 : les menaces principales

L'OWASP (Open Web Application Security Project) publie un classement des dix vulnérabilités les plus critiques des applications mobiles. Ce référentiel est la base de toute stratégie de sécurité mobile sérieuse. Voici les menaces les plus courantes et comment s'en protéger.

Stockage de données non sécurisé

C'est la vulnérabilité la plus fréquente. De nombreuses applications stockent des données sensibles (tokens d'authentification, informations personnelles, données de paiement) en clair sur l'appareil, dans des fichiers de préférences, des bases de données SQLite non chiffrées ou des logs. Un attaquant ayant accès physique à l'appareil ou utilisant un malware peut extraire ces données. La protection consiste à utiliser les mécanismes de stockage sécurisé de chaque plateforme : le Keychain sur iOS et le Keystore sur Android pour les secrets, et le chiffrement de la base de données locale pour les données sensibles.

Communication réseau non sécurisée

Toute communication entre l'application et le serveur doit être chiffrée en HTTPS/TLS. Les attaques man-in-the-middle sur les réseaux Wi-Fi publics permettent d'intercepter les données en transit si le chiffrement est absent ou mal configuré. Au-delà du HTTPS obligatoire, le certificate pinning renforce la sécurité en vérifiant que le certificat du serveur correspond à celui attendu par l'application. Cette technique empêche les attaques utilisant des certificats frauduleux, même si l'utilisateur a installé un certificat racine malveillant sur son appareil.

Authentification et gestion de session faibles

Une authentification mal implémentée est une porte d'entrée majeure pour les attaquants. Les erreurs les plus courantes incluent l'absence de limitation du nombre de tentatives de connexion (permettant les attaques par force brute), des tokens de session qui n'expirent jamais, l'envoi de mots de passe en clair dans les logs et l'absence de vérification côté serveur des permissions utilisateur. Les bonnes pratiques incluent l'utilisation de JWT avec expiration courte, le stockage sécurisé des tokens, la mise en place de refresh tokens et l'authentification multi-facteurs pour les opérations sensibles.

Injection de code et rétro-ingénierie

Les applications mobiles sont distribuées sous forme de binaires que les attaquants peuvent analyser, décompiler et modifier. La rétro-ingénierie permet d'extraire des clés API, de comprendre la logique métier et de créer des versions modifiées de l'application. Pour se protéger, utilisez l'obfuscation du code (ProGuard/R8 sur Android), la détection de root/jailbreak, la vérification de l'intégrité de l'application et ne stockez jamais de secrets sensibles dans le code source. Les clés API et les configurations sensibles doivent être récupérées dynamiquement depuis le serveur, pas embarquées dans l'application.

Chiffrement et stockage sécurisé des données

Le chiffrement est la première ligne de défense pour protéger les données de vos utilisateurs. Il doit être appliqué à la fois au repos (données stockées) et en transit (données échangées sur le réseau).

Chiffrement au repos

Les données sensibles stockées sur l'appareil doivent être chiffrées. Sur iOS, le Keychain Services offre un stockage sécurisé protégé par le matériel (Secure Enclave) pour les mots de passe, tokens et clés. Sur Android, le Keystore system fournit un niveau de protection équivalent. Pour les données plus volumineuses, comme une base de données locale contenant des informations personnelles, utilisez le chiffrement de la base de données : SQLCipher pour SQLite ou le chiffrement natif de Realm. Le chiffrement AES-256 est le standard recommandé. Les clés de chiffrement elles-mêmes doivent être stockées dans le Keychain ou le Keystore, jamais en dur dans le code.

Chiffrement en transit

Toutes les communications réseau doivent utiliser TLS 1.2 ou supérieur. Sur iOS, App Transport Security (ATS) impose HTTPS par défaut. Sur Android, la Network Security Configuration permet de définir précisément les règles de sécurité réseau. Désactiver ces protections pour faciliter le développement est une pratique dangereuse qui risque de persister en production. Configurez votre serveur pour n'accepter que les versions récentes de TLS et les suites de chiffrement les plus robustes. Des outils comme Qualys SSL Labs permettent de tester la configuration SSL de votre serveur.

Gestion sécurisée des mots de passe

Les mots de passe des utilisateurs ne doivent jamais être stockés en clair, ni sur l'appareil, ni sur le serveur. Côté serveur, utilisez un algorithme de hachage adapté comme bcrypt, scrypt ou Argon2 avec un sel (salt) unique par utilisateur. Côté application, ne stockez jamais le mot de passe localement : stockez uniquement le token d'authentification dans le Keychain/Keystore. Encouragez l'utilisation de l'authentification biométrique (Face ID, Touch ID, empreinte digitale) pour réduire la dépendance aux mots de passe et améliorer à la fois la sécurité et l'expérience utilisateur.

Conformité RGPD pour les applications mobiles

Le Règlement Général sur la Protection des Données (RGPD) s'applique à toute application mobile qui collecte ou traite des données personnelles d'utilisateurs résidant dans l'Union Européenne. La non-conformité expose votre entreprise à des amendes pouvant atteindre 4 pour cent du chiffre d'affaires annuel mondial ou 20 millions d'euros.

Le consentement éclairé

Votre application doit obtenir le consentement explicite et éclairé de l'utilisateur avant de collecter ses données personnelles. Ce consentement doit être libre (pas de case pré-cochée), spécifique (un consentement par finalité), éclairé (l'utilisateur comprend ce à quoi il consent) et univoque (une action positive claire). Affichez une politique de confidentialité accessible et compréhensible qui détaille les données collectées, les finalités du traitement, la durée de conservation et les droits de l'utilisateur. Le consentement doit pouvoir être retiré aussi facilement qu'il a été donné.

Minimisation et finalité des données

Le RGPD impose de ne collecter que les données strictement nécessaires à la finalité déclarée. Si votre application de livraison a besoin de l'adresse de livraison, elle n'a pas besoin de l'accès aux contacts téléphoniques de l'utilisateur. Chaque permission demandée doit être justifiable par une fonctionnalité concrète de l'application. Les données collectées ne peuvent être utilisées que pour les finalités pour lesquelles le consentement a été donné. Réaliser un profilage publicitaire avec des données collectées pour « améliorer le service » constitue un détournement de finalité sanctionnable.

Droits des utilisateurs

Votre application doit permettre aux utilisateurs d'exercer leurs droits RGPD : droit d'accès (consulter toutes les données collectées), droit de rectification (corriger des données incorrectes), droit à l'effacement (supprimer leur compte et toutes les données associées), droit à la portabilité (exporter leurs données dans un format lisible) et droit d'opposition (refuser certains traitements). Apple et Google exigent également que les applications proposent un mécanisme de suppression de compte accessible directement depuis l'application.

Audit de sécurité et tests de pénétration

La sécurité n'est pas un état, c'est un processus continu. Les audits réguliers et les tests de pénétration sont indispensables pour identifier et corriger les vulnérabilités avant qu'elles ne soient exploitées.

L'audit de sécurité statique (SAST)

L'analyse statique du code source détecte les vulnérabilités potentielles sans exécuter l'application. Des outils comme SonarQube, Checkmarx ou Snyk analysent le code à la recherche de failles connues : injection SQL, cross-site scripting, dépendances vulnérables, secrets embarqués dans le code. Intégrez ces outils dans votre pipeline de développement (CI/CD) pour détecter les problèmes automatiquement à chaque commit. Cette approche préventive est bien moins coûteuse que la correction de vulnérabilités découvertes en production.

Les tests de pénétration (pentest)

Un pentest est un audit de sécurité réalisé par un expert qui simule les techniques d'un attaquant réel. Le pentester teste la résistance de l'application aux attaques courantes : interception réseau, manipulation des requêtes API, extraction de données locales, contournement de l'authentification et escalade de privilèges. Le rapport de pentest liste les vulnérabilités trouvées, leur niveau de criticité et les recommandations de correction. Un pentest complet coûte entre 5 000 et 15 000 euros selon la complexité de l'application, un investissement modeste au regard des conséquences potentielles d'une faille de sécurité exploitée.

La surveillance continue

Après le déploiement, mettez en place une surveillance continue de la sécurité. Utilisez un outil de monitoring des dépendances pour être alerté quand une librairie utilisée par votre application fait l'objet d'une alerte de sécurité. Surveillez les logs d'accès API pour détecter les comportements anormaux (pics de requêtes, tentatives de connexion multiples, accès à des endpoints non documentés). Planifiez des audits de sécurité réguliers, au minimum une fois par an ou à chaque évolution majeure de l'application.