Audit sécurité application mobile iOS et Android : guide 2026

M1 — Utilisation inappropriée des plateformes : Mauvaise utilisation des fonctionnalités de sécurité natives iOS/Android (permissions excessives, URL schemes non filtrés, mauvaise utilisation du Keychain/Keystore).

M2 — Stockage de données non sécurisé : Données sensibles stockées en clair dans les fichiers de l'application, SharedPreferences, bases SQLite non chiffrées, logs applicatifs ou backups. C'est l'une des vulnérabilités les plus fréquentes.

M3 — Communications non sécurisées : Trafic en HTTP (non chiffré), mauvaise validation des certificats TLS permettant des attaques Man-in-the-Middle, certificats épinglés (certificate pinning) absents ou mal implémentés.

M4 — Authentification non sécurisée : Mécanismes d'authentification insuffisants, absence de verrouillage après tentatives échouées, tokens de session stockés insécurisés ou non renouvelés.

M5 — Cryptographie insuffisante : Utilisation d'algorithmes obsolètes (DES, RC4), clés codées en dur dans le code, IV fixes pour les chiffrements par blocs.

Analyse statique (SAST) : Analyse du code sans exécution de l'application. Sur Android, nous analysons l'APK décompilé (via apktool, jadx) pour identifier les permissions déclarées, les secrets codés en dur (clés API, mots de passe), les bibliothèques vulnérables, les communications réseau définies et les failles de logique métier. Sur iOS, nous analysons l'IPA et le binaire compilé via Hopper ou Ghidra pour les applications sans accès au code source.

Analyse dynamique (DAST) : Analyse en cours d'exécution sur un appareil physique ou un émulateur. Nous interceptons les communications réseau via Burp Suite (avec certificate pinning bypassé si nécessaire via Frida), analysons le stockage de données créé lors de l'utilisation, monitorons les appels système, et testons les mécanismes d'authentification et de gestion des sessions.

Reverse engineering : Décompilation du code pour comprendre la logique métier et identifier les failles algorithmiques. Outils principaux : jadx (Android), Hopper/Ghidra (iOS), Frida (hooking dynamique sur Android et iOS).

iOS : L'écosystème fermé Apple offre un modèle de sécurité plus strict (sandboxing, App Store review, Gatekeeper). Les vulnérabilités iOS sont souvent liées à une mauvaise utilisation du Keychain, des URL schemes mal sécurisés, l'absence de jailbreak detection, et des problèmes de confidentialité (accès excessifs aux photos, localisation, contacts). L'audit nécessite idéalement un accès au code source (Swift/Objective-C) ou un appareil jailbreaké pour les tests dynamiques avancés.

Android : L'écosystème ouvert Android offre plus de surface d'attaque : applications tierces (APK hors Play Store), permissions granulaires, Intents non filtrés, Content Providers exposés, WebViews avec JavaScript activé. La fragmentation des versions Android (nombreux appareils sous Android 8 ou 9) complexifie également le patching des vulnérabilités système.

Utiliser le Keychain (iOS) ou le Keystore Android pour stocker tous les secrets (tokens, clés) — jamais dans SharedPreferences ou des fichiers en clair. Implémenter le certificate pinning pour les communications API critiques. Activer le root/jailbreak detection pour les applications à haute sensibilité. Chiffrer les bases de données locales (SQLCipher). Minimiser les permissions demandées (demander uniquement au moment où elles sont nécessaires). Mettre en place l'obfuscation du code (ProGuard/R8 pour Android, diverses techniques pour iOS). Intégrer un RASP (Runtime Application Self-Protection) pour les applications bancaires ou de santé.

Un audit de sécurité mobile complet (iOS + Android) prend généralement 8 à 15 jours selon la complexité de l'application. Il est fortement recommandé avant chaque release majeure et lors de changements d'architecture. Pour les applications traitant des données de paiement, l'audit est souvent requis par la norme PCI-DSS.