OWASP Mobile Top 10 : qu'est-ce que c'est, liste des vulnérabilités et comment l'appliquer

Qu'est-ce que OWASP Mobile Top 10 ?

OWASP Mobile Top 10 est une liste standardisée des risques de sécurité les plus critiques spécifiques aux applications mobiles. Contrairement à l'OWASP Top 10 général pour les applications web, la version mobile prend en compte les spécificités des plateformes : stockage local sur l'appareil, interaction avec les capteurs, modes hors ligne et particularités des magasins d'applications. Le document est publié depuis 2010 et est révisé tous les 2–4 ans : la version actuelle de 2024 inclut des catégories telles que M1 — Improper Credential Usage et M8 — Security Misconfiguration. Le projet est soutenu par une communauté de plus de 500 bénévoles dans le monde entier.

Histoire et objectif

À l'origine, OWASP Top 10 ne couvrait que les applications web, mais la croissance du développement mobile dans les années 2010 a nécessité un document séparé. La première version de Mobile Top 10 est sortie en 2011 et ne contenait que 7 éléments. En 2024, la liste s'est élargie à 10 catégories, chacune incluant plusieurs scénarios d'attaque spécifiques. L'objectif principal du document est de donner aux développeurs et aux équipes de sécurité un langage commun pour discuter des risques et prioriser les correctifs. Les mises à jour régulières de la liste reflètent l'évolution du paysage des menaces : l'émergence de nouvelles API, l'évolution des systèmes d'exploitation (Android, iOS) et les nouvelles techniques d'attaque décrites dans les rapports de Positive Technologies et d'autres centres de recherche.

Comment la liste OWASP Mobile Top 10 est formée

La méthodologie de compilation du Mobile Top 10 est basée sur des données provenant de projets réels : les résultats de tests d'intrusion d'applications mobiles, les rapports d'incidents et les recherches de vulnérabilités sont analysés. Chaque catégorie est évaluée selon deux paramètres : le taux d'incidence (Incidence Rate) et l'impact technique (Technical Impact). La combinaison de ces métriques forme le classement final. Contrairement aux listes subjectives, OWASP utilise des données ouvertes : tout membre de la communauté peut soumettre une demande d'inclusion d'une nouvelle catégorie via le référentiel GitHub du projet. Pour la version actuelle de 2024, plus de 300 000 tests de sécurité provenant de 25 pays ont été traités, rendant les statistiques représentatives de l'écosystème mondial du développement mobile. De plus, OWASP publie MASVS (Mobile Application Security Verification Standard) — un ensemble d'exigences de sécurité détaillées qui comprend plus de 80 vérifications spécifiques réparties dans 8 catégories. MASVS est utilisé comme base pour la certification des applications et comme liste de contrôle pour les tests d'intrusion : chaque exigence a une référence à une catégorie de Mobile Top 10, assurant la traçabilité entre la norme et la liste des risques.

Aperçu des vulnérabilités clés du top 10

Examinons les trois catégories les plus critiques de l'OWASP Mobile Top 10 2024, qui couvrent plus de 70% de tous les incidents de sécurité dans les projets mobiles. Chaque catégorie comprend des scénarios d'exploitation spécifiques et des recommandations de protection.

Utilisation incorrecte de la plateforme

Cette catégorie (M1) couvre les situations où les développeurs utilisent des API et des mécanismes de plateforme de manière incorrecte. Exemples typiques : Intent Injection sur Android, gestionnaires de Deep Link ouverts sur iOS, manipulation incorrecte de Keychain et SharedPreferences. Un attaquant peut envoyer un Intent spécialement conçu et obtenir un accès aux données d'une autre application ou d'un composant. Selon le rapport de NowSecure (2023), 22% des applications Android testées contenaient des vulnérabilités de type Intent Redirection. La protection comprend : une validation stricte des données d'entrée, la vérification de la source de l'Intent et l'utilisation d'autorisations pour les composants exportés.

Stockage non sécurisé des données

Stockage non sécurisé des données (M2) est le problème le plus courant dans les applications mobiles. Il survient lorsque des données sensibles (jetons d'accès, mots de passe, données personnelles) sont stockées en texte clair ou avec une protection insuffisante. Sources typiques de vulnérabilité : bases de données SQLite sans chiffrement, SharedPreferences sans EncryptedSharedPreferences, journalisation des données en mode débogage. Selon l'OWASP Foundation (2024), plus de 60% des applications gratuites sur Google Play stockent au moins un type de données sensibles sous forme non chiffrée. La solution consiste à utiliser Android EncryptedSharedPreferences, iOS Keychain et à chiffrer les données avant de les écrire dans le stockage local.

Communication non sécurisée

La catégorie M3 — Communication non sécurisée — inclut les vulnérabilités dans les canaux de transmission de données entre l'application et le serveur. L'absence de HTTPS, la validation incorrecte des certificats SSL, l'utilisation de protocoles TLS 1.0/1.1 obsolètes — tous ces problèmes permettent à un attaquant d'intercepter le trafic via des attaques Man-in-the-Middle. La situation est particulièrement dangereuse lorsque l'application traite des données sensibles (transactions bancaires, informations médicales) via un canal non protégé. En 2023, des chercheurs de NCC Group ont découvert que 12% des applications financières populaires utilisent une configuration TLS incorrecte. Recommandation : utilisation obligatoire de HTTPS avec Certificate Pinning et rejet de HTTP dans les versions de production.

Comment tester les applications selon OWASP Mobile Top 10

Le test de sécurité d'une application mobile selon la méthodologie OWASP comprend plusieurs étapes : l'analyse statique de code (SAST), l'analyse dynamique (DAST) et les tests manuels (test d'intrusion). Chaque étape vise à identifier des catégories spécifiques de vulnérabilités de Mobile Top 10.

Outils de test

Pour l'analyse automatisée, OWASP recommande d'utiliser MobSF (Mobile Security Framework) — un outil open source. MobSF effectue une analyse statique du code source et des fichiers binaires, vérifie la configuration du manifeste, analyse les autorisations et identifie les vulnérabilités de Mobile Top 10. Pour l'analyse dynamique, Burp Suite (proxy d'interception de trafic) et Frida (outil d'analyse d'exécution) sont utilisés. La combinaison de ces outils couvre plus de 80% des catégories de la liste. Des tests réguliers dans un pipeline CI/CD avec MobSF permettent d'identifier les vulnérabilités aux premiers stades du développement et réduisent le coût de leur correction de 60–70%. L'intégration des outils SAST et DAST dans le pipeline doit être automatisée via des plugins Gradle/Maven ou des étapes Fastlane dans les builds iOS.

Interprétation du rapport MobSF

Après avoir exécuté MobSF, le développeur reçoit un rapport avec des indicateurs de couleur : rouge — vulnérabilité critique, orange — risque moyen, jaune — risque faible. Chaque avertissement contient une référence à la catégorie OWASP Mobile Top 10 correspondante, une description du problème et une recommandation de correction. Il est important non seulement d'éliminer les avertissements rouges, mais aussi d'analyser les oranges : beaucoup d'entre eux (par exemple, les activités exportées sans protection) peuvent se combiner pour donner à un attaquant un vecteur d'attaque. Il est recommandé d'atteindre zéro avertissement rouge et pas plus de 2–3 oranges avant chaque publication. Le rapport MobSF comprend également une analyse des autorisations de l'application : toute autorisation excessive (par exemple, l'accès à la caméra dans une calculatrice) est signalée comme une violation du principe du moindre privilège et doit être supprimée du manifeste. Pour les applications iOS, MobSF effectue une analyse similaire des fichiers .ipa, y compris la vérification d'Info.plist pour les exceptions ATS et l'analyse des binaires Mach-O pour les API non sécurisées telles que NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}