Découvrez à quoi ressemble un rapport Agentic Deep Scan mobile
Le rapport complet et non retouché d'un scan d'AndroGoat, une application Android volontairement vulnérable utilisée pour les formations OWASP. Il montre comment chaque vulnérabilité est reliée au code vulnérable, prouvée et corrigée.
- Cible
- AndroGoat (Android)
- Scan
- Mobile Agentic Deep Scan
- Longueur
- 200 pages
- Résultat
- Risque global : élevé
Réalisé sur une application de formation volontairement vulnérable. Aucune donnée client.
Contenu du rapport
Périmètre et contexte
Ce qui a été testé et comment, et ce que fait l'application, avant toute vulnérabilité.
Synthèse
Les principaux risques en langage clair, du stockage non sécurisé aux failles d'injection.
Vulnérabilités au niveau du code
Chaque vulnérabilité présente la cause, le code vulnérable et les preuves d'exploitation.
Validation et correctifs
Une seconde passe confirme chaque vulnérabilité, suivie du correctif recommandé et des références.
Vulnérabilité annotée
Une vulnérabilité, étape par étape
Comment le rapport mène une vulnérabilité du build exact qui a été testé jusqu’au correctif. Chaque étape renvoie à sa page dans le rapport complet.
- Build
AndroGoat 1.0 (1), package owasp.sat.agoat
Le rapport identifie l’APK exact par son empreinte SHA-256 et le rattache au commit 1f38398 du dépôt public AndroGoat.
Page 2 du rapport - Appareil
Émulateur Android 11
Les tests dynamiques ont tourné sur un émulateur Android 11 (API 30) avec accès root, où l’agent a installé et lancé l’application.
Page 7 du rapport - Périmètre
L’application Android seule, sans identifiants de test
Un Mobile Agentic Deep Scan de l’APK, exécuté les 19 et 20 mai 2026. iOS, l’API backend et les composants web étaient hors périmètre.
Page 2 du rapport - Parcours
Les écrans de connexion de l’application
AndroGoat n’a pas de serveur : ses écrans de connexion et de code PIN tournent sur l’appareil. L’agent a suivi ce que ces écrans font du nom d’utilisateur et du mot de passe saisis.
Page 27 du rapport - Vulnérabilité
Élevée : identifiants stockés en clair
Les noms d’utilisateur et mots de passe sont écrits en clair dans les SharedPreferences, une base SQLite et des fichiers temporaires, dont un sur le stockage partagé. Les sauvegardes sont aussi activées.
Page 27 du rapport - Preuve
Le fichier d’identifiants, lu par un autre utilisateur
Le rapport montre le code vulnérable, puis une preuve à l’exécution : lire le fichier d’identifiants sur la carte SD en tant qu’autre utilisateur a renvoyé tout son contenu en clair.
Page 8 du rapport - Correctif
Chiffrer, et garder les identifiants hors du stockage partagé
Désactiver les sauvegardes et chiffrer les données stockées sans attendre. Le correctif durable déplace les identifiants vers EncryptedSharedPreferences, adossé au KeyStore, avec un exemple de code.
Page 29 du rapport - Vérification
Comment confirmer le correctif
Rechercher dans l’application décompilée des identifiants passés en clair aux appels de stockage, et vérifier qu’une sauvegarde adb n’expose plus de fichier d’identifiants lisible.
Page 29 du rapport
Comment l'agent a tranché
Pourquoi c'est un vrai risque
Un scanner signale tout ce qui correspond à une règle. Avant de signaler un problème, l'agent vérifie qu'un indice mène à un vrai dommage. Voici son raisonnement sur un indice trouvé dans l'application AndroGoat.
Étape 1
Que fait cette adresse dans l'application ?
Les ressources de l'application contiennent l'adresse d'une base de données Firebase, androgoat-42597.firebaseio.com, dans res/values/strings.xml.
Page 79 du rapportÉtape 2
L'application l'utilise-t-elle vraiment ?
Non. Il n'y a aucune bibliothèque Firebase et aucun code ne lit cette valeur. Une vérification par règles la classerait comme un reste inutilisé et passerait à autre chose.
Page 10 du rapportÉtape 3
La base de données elle-même est-elle ouverte ?
L'agent a envoyé une requête à la base de données sans se connecter. Elle a répondu 200 OK et renvoyé un nom d'utilisateur et un mot de passe.
Page 80 du rapportÉtape 4
Alors, est-ce un risque ?
Oui, élevé. Peu importe que l'application ignore l'adresse : quiconque décompresse l'application peut trouver la base de données et la lire sans compte.
Page 41 du rapportÉtape 5
Comment le corriger ?
Activer Firebase Authentication et les règles de sécurité pour que la lecture de la base de données exige un utilisateur connecté, et retirer l'adresse inutilisée de l'application.
Page 41 du rapport
Vous voulez ce rapport pour votre propre application ?
Réservez une démo et nous vous présenterons un scan de votre application mobile, de votre application web ou de votre API.