Découvrez à quoi ressemble un rapport Agentic Deep Scan web
Une évaluation de 227 pages de VulnBank, une application bancaire volontairement vulnérable, et de son API. Elle montre comment chaque vulnérabilité est prouvée par des requêtes reproductibles, notée et rattachée à sa cause première.
- Cible
- Application web et API VulnBank
- Scan
- Web Agentic Deep Scan
- Longueur
- 227 pages
- Résultat
- Risque global : critique
Réalisé sur une cible de démonstration volontairement vulnérable. Aucune donnée client.
Contenu du rapport
Synthèse
Le risque global, les principaux chemins d'attaque et les priorités de correction, dès les premières pages.
Tableau des vulnérabilités
Chaque vulnérabilité avec son niveau de risque, son score CVSS, son statut et une courte description.
Exploits prouvés
Une analyse détaillée des principales vulnérabilités critiques et élevées, avec preuves et impact métier.
Comment corriger
La cause première de chaque vulnérabilité et la façon de la corriger, avec des étapes de reproduction à rejouer.
Vulnérabilité annotée
Une vulnérabilité, étape par étape
Comment le rapport mène une vulnérabilité de la cible testée jusqu’au correctif. Chaque étape renvoie à sa page dans le rapport complet.
- Cible
vulnbank.org, une banque de démonstration en ligne
Une application de banque en ligne et son API, volontairement vulnérables et conçues pour la formation en sécurité, testées en conditions réelles. Le rapport décrit ses fonctionnalités et la technologie observée.
Page 2 du rapport - Périmètre
Un domaine, tous les endpoints trouvés
Connexion, virements, prêts, cartes, téléversements, panneau d'administration et API de l'agent IA, testés du 14 décembre 2025 au 16 mars 2026 sans identifiants de test. Les sous-domaines étaient hors périmètre.
Page 2 du rapport - Méthode
Chaque vulnérabilité est accompagnée de sa preuve
Les agents explorent l'application et tentent chaque attaque. Les vulnérabilités confirmées incluent les requêtes qui les reproduisent et des tentatives de validation ; les pistes non confirmées sont signalées comme potentielles.
Page 7 du rapport - Parcours
Connexion et contrôle d’accès
La vulnérabilité se situe dans la couche de connexion et d’autorisation qui protège chaque requête, y compris les fonctions d’administration.
Page 48 du rapport - Vulnérabilité
Critique (CVSS 9.8) : jetons d’accès non vérifiés
Le serveur acceptait des jetons d’accès sans vérifier leur authenticité : le panneau et les actions d’administration étaient accessibles sans compte.
Page 48 du rapport - Preuve
Les requêtes et réponses qui le prouvent
Le rapport montre les requêtes et réponses du scan, abrégées : une requête sans jeton valide est refusée, puis le contrôle est contourné et une action d’administration aboutit.
Page 49 du rapport - Correctif
Vérifier chaque jeton, contrôler les rôles côté serveur
Le rapport attribue la faille à des jetons décodés sans vérification de signature, et à une autorisation qui fait confiance à la valeur is_admin contenue dans le jeton. La correction : vérifier chaque signature et charger le rôle de l'utilisateur côté serveur.
Page 58 du rapport - Statut
Notée, classée et suivie
Le tableau des vulnérabilités liste chaque problème avec son niveau de risque, son score CVSS, son statut et une courte description.
Page 20 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 et écarte les explications inoffensives. Voici son raisonnement sur une vulnérabilité de vulnbank.org.
Étape 1
Pourquoi la page de solde répond-elle sans connexion ?
GET /check_balance/<numéro de compte> a renvoyé 200 avec le nom d'utilisateur et le solde d'un autre client, sans jeton ni cookie.
Page 23 du rapportÉtape 2
Serait-ce une copie en cache ?
L'agent a renvoyé la requête avec des en-têtes no-cache et un nonce unique. La réponse indiquait cf-cache-status: DYNAMIC : elle venait du serveur, pas d'un cache.
Page 24 du rapportÉtape 3
Le point d'accès est-il simplement tolérant avec les jetons ?
Une requête avec un faux jeton, Bearer invalid, a reçu le même 200 et les mêmes données. Le point d'accès ne vérifie pas le jeton du tout.
Page 24 du rapportÉtape 4
S'agit-il de vraies données ou d'une démo figée ?
Connecté en tant qu'utilisateur, l'agent a fait un virement de 12,34, puis a lu les transactions de cet utilisateur sans se connecter. La nouvelle transaction y figurait.
Page 25 du rapportÉtape 5
D'où vient le problème ?
POST /transfer refuse une requête sans jeton avec un 401 : l'authentification existe, mais elle n'est pas appliquée à ces deux lectures. La spécification de l'API les déclare sans aucune sécurité.
Page 26 du rapportÉtape 6
Alors, est-ce un risque ?
Oui, critique. N'importe qui sur Internet peut lire les soldes et l'historique des transactions, et se servir des réponses 200 ou 404 pour trouver des numéros de compte valides.
Page 27 du rapportÉtape 7
Comment le corriger ?
Exiger un jeton valide sur les deux points d'accès et renvoyer 401 sans jeton. Puis vérifier que le compte appartient à l'appelant, et renvoyer 403 sinon.
Page 27 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.