Web, API et mobile, c'est la même démarche : seule la forme du client change. L'objectif n'est pas seulement de trouver une RCE, c'est d'auditer l'application : cloisonnement, contrôle d'accès (BOLA/IDOR), logique métier, authentification et session, désérialisation. Les failles qui comptent le plus ne sont pas dans une CVE, elles sont dans le comportement de votre code.
BOLA / IDOR, élévation de privilèges horizontale et verticale, contournement de workflow, accès aux objets d’un autre utilisateur.
Manipulation de prix ou de quotas, contournement d’étapes, abus de fonctionnalités légitimes : les failles qu’aucun scanner ne décrit.
JWT, OAuth 2.0 / OIDC, SSO, MFA contournable, réinitialisation de mot de passe, account takeover.
RCE, injections SQL / NoSQL, SSRF, XXE, XSS, upload de fichiers, désérialisation non sécurisée.
Données sensibles exposées, mass assignment, énumération d’objets, contrôles insuffisants côté serveur (BOPLA).
Bibliothèques tierces vulnérables, versions obsolètes, secrets exposés dans les bundles, supply chain.
Sur un test applicatif, la « boîte » correspond à ce que vous nous donnez au départ. Plus vous nous en donnez, un compte, puis le code source, plus on couvre les fonctionnalités authentifiées et la logique métier en profondeur, au lieu de passer du temps à deviner. Nos experts vous conseillent selon ce que vous voulez mesurer.
Vous ne nous donnez qu'une URL (ou le binaire de l'app), zéro compte. Exactement la position d'un attaquant anonyme face à votre application. On cartographie la surface exposée, on cherche les failles accessibles avant authentification et les contournements de connexion.
Vous nous fournissez un ou plusieurs comptes utilisateur standard (idéalement deux, pour tester le cloisonnement). On accède aux fonctionnalités authentifiées et on attaque là où sont les failles à fort impact : BOLA/IDOR, élévation de privilèges, logique métier. L'approche la plus utilisée sur un test applicatif.
Vous fournissez le code source, un compte administrateur et la documentation. Objectif : ne rien laisser de côté, vérifier chaque rôle et chaque branche de la logique, y compris les chemins qu'une attaque externe ne déclencherait jamais. Couverture maximale, temps de reconnaissance réduit.
Un test applicatif sans rapport actionnable ne sert à rien. Chaque mission produit des livrables précis, exploitables immédiatement par la direction et les équipes de développement.
Synthèse en 4–6 pages pour la direction : niveau de risque applicatif global, top des vulnérabilités critiques, impact métier estimé, priorités de remédiation.
Chaque vulnérabilité documentée : preuve d'exploitation (requêtes, captures), impact réel, remédiation détaillée pour les développeurs, références OWASP/CWE.
Cartographie des fonctionnalités et rôles testés (web, API, mobile), avec ce qui a été couvert et la profondeur atteinte, pour savoir précisément ce qui a été audité.
Vulnérabilités classées par priorité, avec effort estimé, type d'action (correctif de code, configuration, mise à jour de dépendance) et difficulté pour les équipes.
Restitution direction et technique (deep-dive avec les développeurs), puis retest des vulnérabilités critiques après correction et attestation de remédiation.
Définition du périmètre (URL, endpoints API, app mobile, rôles à fournir), règles d'engagement, environnement (prod ou recette). Comptes de test, autorisation de test et NDA.
Appel + documentCartographie des fonctionnalités et endpoints, tests manuels du contrôle d'accès, de la logique métier et de l'authentification, puis exploitation. Communication immédiate sur faille critique.
Test liveRapports exécutif et technique + couverture fonctionnelle, vérification croisée par un second expert. Livraison sous 5 jours après la fin des tests.
Rapport sous 5 joursSession direction et session technique avec les développeurs. Plan de remédiation priorisé, début du suivi des questions post-rapport.