Test d'intrusion d'application web
Des tests manuels, fondés sur l'exploitation réelle, selon l'OWASP Top 10 et au-delà : pas un export de scanner.
Un scanner automatique remonte trois cents alertes, dont la plupart ne sont que du bruit. Nous testons à la main, comme le ferait un attaquant : en essayant de transformer une petite erreur de contrôle d'accès en lecture des données d'un autre client, ou un champ de formulaire en exploitation qui fonctionne. Vous recevez une chaîne d'exploitation prouvée et un correctif pour chaque faille réelle, puis un contre-test une fois les corrections appliquées, pas un PDF rempli de faux positifs.
Comment ça se passe
- 1
Cartographier la surface d'attaque
Chaque point d'accès, formulaire, rôle et intégration est recensé avant toute tentative d'exploitation : rien n'est testé à l'aveugle.
- 2
Tester à la main, enchaîner quand c'est possible
Une petite erreur de configuration peut sembler mineure ; nous vérifions si elle s'enchaîne vers quelque chose de grave, comme le ferait un vrai attaquant.
- 3
Prouver, pas affirmer
Chaque faille est livrée avec une preuve qui fonctionne : la requête, la réponse et ce qu'elle expose réellement.
- 4
Contre-tester après correction
Une fois le correctif déployé, nous testons de nouveau cette faille précise pour confirmer qu'elle est vraiment fermée, et pas seulement masquée.
Questions fréquentes
Quelle différence avec un scanner de vulnérabilités que nous lancerions nous-mêmes ?
Les tests risquent-ils de casser notre site en production ?
Que se passe-t-il si vous trouvez une faille critique ?
Souvent associé à Conseil en cybersécurité et Sécurité de l'infrastructure cloud.
Pour savoir comment se passe un test, lisez notre guide : Test d'intrusion d'une application web : déroulé, livrables et durée.
Dites-nous ce qu'il vous faut.
Un paragraphe suffit. Vous aurez une réponse franche sur la pertinence du projet, ce qu'il implique à peu près, et la suite.