Un test d'intrusion d'application web, c'est une attaque réelle, autorisée et encadrée, contre votre application, menée à la main pour trouver ce qu'un attaquant pourrait exploiter, puis pour le prouver et le faire corriger. Ce n'est pas un rapport de scanner automatique : la différence se voit dans le déroulé et, surtout, dans le livrable.
Ce guide décrit comment se déroule un test, ce qu'un rapport utile doit contenir, ce qui fait varier la durée, et comment le préparer. À la fin, vous trouverez notre propre offre de test d'intrusion d'application web.
Les étapes d'un test d'intrusion
- Le cadrage. Le périmètre (domaines, applications, API), les comptes de test, les horaires et les tests exclus sont fixés par écrit. C'est ce document qui rend le test légal et sans surprise.
- La cartographie. Chaque page, formulaire, point d'accès d'API, rôle et intégration est recensé avant toute tentative d'exploitation. Rien n'est testé à l'aveugle.
- Les tests manuels. L'application est attaquée selon les catégories de l'OWASP Top 10 et au-delà : contrôle d'accès, injection, authentification, gestion des sessions, logique métier. Une petite faiblesse est testée pour voir si elle s'enchaîne vers quelque chose de grave.
- La preuve. Chaque faille réelle est démontrée : la requête, la réponse, et ce qu'elle expose. Une faille critique est signalée immédiatement, sans attendre le rapport.
- Le rapport. Les failles sont classées par gravité, chacune avec un correctif concret.
- Le contre-test. Une fois les corrections déployées, chaque faille est testée de nouveau pour confirmer qu'elle est vraiment fermée.
Ce qu'un rapport utile doit contenir
- Un résumé lisible par une direction : ce qui est exposé, et ce qu'il faut corriger d'abord.
- Pour chaque faille : la description, l'impact réel, la preuve d'exploitation et le correctif recommandé.
- Un classement par gravité fondé sur l'exploitabilité réelle, pas sur un score théorique.
- Le périmètre testé et ce qui ne l'a pas été, pour que personne ne prenne le rapport pour plus qu'il n'est.
- Le résultat du contre-test.
Un rapport de cent pages rempli d'alertes de scanner n'aide personne. Un bon rapport est court là où il peut l'être, et précis là où il doit l'être.
Ce qui fait varier la durée
La durée dépend du périmètre : le nombre de fonctionnalités et de rôles utilisateurs, les intégrations (paiement, API tierces), la présence d'une application mobile qui parle à la même API, et la profondeur demandée. Un test en boîte grise, avec des comptes de test pour chaque rôle, va plus loin dans le même temps qu'un test en boîte noire, sans aucun accès.
Comment préparer le test
- Un environnement de préproduction aussi proche que possible de la production.
- Un compte de test pour chaque rôle (client, gestionnaire, administrateur).
- La liste des domaines et des API concernés, et des intégrations à ne pas solliciter.
- Un interlocuteur joignable pendant le test, pour une faille critique.
Notre offre
Notre test d'intrusion d'application web suit ce déroulé : tests manuels selon l'OWASP Top 10 et au-delà, une preuve d'exploitation pour chaque faille réelle, des failles classées par gravité avec un correctif pour chacune, et un contre-test gratuit une fois les corrections déployées. Chaque mission est cadrée et chiffrée par écrit avant de commencer. Écrivez-nous sur WhatsApp pour en parler.