Quelle structure attendre d’un rapport de pentest web ?
Les rubriques ci-dessous constituent une grille de lecture pour examiner un rapport et préparer vos attentes. Elles expliquent les informations à rechercher, sans imposer une mise en page unique.
1. La synthèse pour la direction
La synthèse doit permettre de comprendre les enjeux sans lire chaque détail technique. Elle rapproche les faiblesses observées des conséquences possibles pour l’activité : accès non autorisé, exposition de données ou perturbation d’un service. Une bonne lecture commence par les priorités et les décisions attendues, plutôt que par le seul nombre de vulnérabilités.
2. Le périmètre et les limites
Le rapport précise les applications, interfaces et rôles utilisateurs concernés, ainsi que les exclusions. La période d’intervention et les conditions d’accès expliquent ce qui a pu être testé. Ces éléments évitent d’étendre une conclusion à des composants non examinés. Avant la mission, obtenez une autorisation écrite et définissez les environnements, les règles d’engagement et les responsabilités des parties.
3. La méthode de test
La méthode décrit la démarche suivie et les catégories de contrôles réalisées. Elle permet de comprendre la place des vérifications manuelles et des outils, sans assimiler un inventaire automatique à un test d’intrusion complet. Les restrictions rencontrées doivent rester visibles : un accès indisponible ou une action exclue limite ce que les résultats permettent de conclure.
4. Les constats techniques
Chaque constat doit être identifiable et relié à un composant du périmètre. L’équipe chargée de corriger a besoin d’étapes reproductibles, de preuves dont les données sensibles sont masquées et de l’impact observé. La gravité doit être justifiée. Ces éléments constituent une trace exploitable des tests ; les preuves complètes nécessitent une transmission et une conservation protégées.
5. Le plan de remédiation
Le passage du constat à l’action demande une correction compréhensible, un responsable et un ordre de traitement. Les dépendances techniques, les contraintes de disponibilité et les mesures temporaires peuvent modifier cet ordre. Les délais d’un exemple ne doivent donc pas être repris tels quels : ils se discutent selon l’exposition réelle, l’impact métier et la capacité des équipes à intervenir.
6. Le suivi et le retest
Une correction déclarée ne suffit pas à démontrer que le problème a disparu. Le retest vérifie les constats concernés après modification et indique ce qui reste ouvert, partiellement corrigé ou non vérifié. Son périmètre et ses conditions sont à convenir. Il ne transforme pas les résultats d’une mission limitée dans le temps en garantie permanente de sécurité.
Pour approfondir la rédaction d’un livrable, consultez la structure de rapport du guide OWASP WSTG. Cette référence éclaire la présentation des résultats ; elle ne certifie pas ce document.