Rédiger un rapport de vulnérabilité clair et actionnable
Vous avez, dans votre carnet de test, une série de constats : des preuves, des captures, des hypothèses. Mais une faille que personne ne comprend ne sera jamais corrigée. Le rapport est la raison d’être d’un audit : c’est lui qui transforme votre travail technique en décisions et en corrections. Un excellent testeur n’est pas seulement celui qui trouve : c’est celui dont les constats sont compris, crus et traités.
Rappel légal et confidentialité
Un rapport contient, par nature, la description de faiblesses d’un système : c’est une information sensible. En mission réelle (réalisée avec une autorisation écrite et dans un périmètre défini, articles 323-1 à 323-3-1 du Code pénal), il est transmis uniquement au client, par un canal sécurisé, et ne contient ni données personnelles inutiles ni secrets en clair. Ici, votre rapport porte sur l’application d’entraînement : vous pouvez le garder dans votre portfolio, en précisant bien qu’il s’agit d’un laboratoire.
À qui s’adresse un rapport ?
Un rapport a presque toujours deux lecteurs aux besoins différents :
| Lecteur | Ce qu’il cherche | Où le trouver dans le rapport |
|---|---|---|
| Décideur (direction, responsable métier) | Le niveau de risque global, les priorités, le coût d’inaction | Synthèse de gestion |
| Équipe technique (développeurs, administrateurs) | Comprendre précisément la faille, la reproduire, la corriger | Constats détaillés et annexes |
Écrire pour les deux est un art : une synthèse sans jargon d’un côté, des détails reproductibles de l’autre.
La structure d’un rapport
- Page de garde et informations de contrôle : titre, version, date, auteur, niveau de confidentialité.
- Synthèse de gestion : une page maximum. Objectif de l’audit, périmètre, appréciation globale du niveau de sécurité, nombre de constats par gravité, trois ou quatre recommandations prioritaires. Sans jargon.
- Contexte et périmètre : ce qui a été testé, ce qui ne l’a pas été, dates, comptes utilisés, conditions (boîte noire, grise ou blanche).
- Méthodologie : le référentiel suivi (par exemple le guide de test de l’OWASP) et les outils utilisés.
- Tableau de synthèse des constats : une ligne par constat, avec identifiant, titre, gravité, état.
- Constats détaillés : la partie principale, une fiche par faille.
- Points positifs : ce qui fonctionne bien. Un rapport honnête ne contient pas que des défauts.
- Conclusion et plan d’action proposé.
- Annexes : preuves volumineuses, résultats bruts, glossaire.
La fiche de constat : le cœur du rapport
Chaque constat suit un modèle constant. C’est le même que celui de votre carnet, enrichi :
| Rubrique | Contenu attendu |
|---|---|
| Identifiant et titre | Un titre précis et factuel (« Absence de protection anti-CSRF sur le changement de mot de passe ») |
| Gravité | Niveau et justification (voir la leçon suivante) |
| Éléments concernés | Pages, paramètres, composants, versions |
| Description | Ce qu’est le défaut, en termes compréhensibles |
| Étapes de reproduction | Une liste numérotée qu’une personne tierce peut suivre |
| Preuve | Captures annotées, extraits de requêtes et de réponses |
| Impact | Ce qu’un attaquant pourrait faire, concrètement, pour cette organisation |
| Recommandation | Une correction précise, avec une alternative si besoin |
| Références | Catégorie OWASP, CVE éventuelle, documentation utile |
Les qualités d’un bon constat
1. Précis
« Le site est vulnérable aux injections » ne sert à rien. « Le paramètre id de la page de profil est inséré dans une requête SQL sans paramétrage » est actionnable. Désignez l’élément exact.
2. Reproductible
Si le développeur ne peut pas refaire l’observation, il ne pourra ni la comprendre ni vérifier sa correction. Notez la version de l’application, le compte utilisé, l’ordre des étapes, la valeur testée, le résultat attendu et le résultat obtenu.
3. Prouvé avec la preuve minimale
La preuve la plus petite qui établit la faille : une capture de la réponse anormale, un extrait. Jamais de données réelles de tiers, jamais de secrets en clair : masquez-les (« caviardage »).
4. Impact qualifié, pas exagéré
L’impact doit rester crédible et rattaché au contexte. Évitez le sensationnalisme (« toute l’entreprise peut être détruite ») et les formulations vagues (« pourrait avoir des conséquences »). Dites ce que la faille permet effectivement dans ce système.
5. Recommandation réaliste
Dites comment corriger : requêtes préparées, ajout d’un en-tête, mise à jour vers une version donnée. Proposez, si c’est pertinent, une mesure à court terme et une solution de fond.
Un exemple de fiche
Constat n° 04 - Cookie de session sans attribut HttpOnly
Gravité : moyenne
Éléments concernés : cookie « session », application d'entraînement (labo)
Description
Le cookie de session est transmis sans l'attribut HttpOnly. Il est
donc lisible par des scripts exécutés dans la page.
Reproduction
1. Se connecter avec le compte de test A.
2. Dans l'historique du proxy, ouvrir la réponse de connexion.
3. Lire l'en-tête Set-Cookie : l'attribut HttpOnly est absent.
Impact
En présence d'une faille XSS (constat n° 06), un script injecté pourrait
lire l'identifiant de session et permettre la reprise de la session.
Recommandation
Ajouter HttpOnly, Secure et SameSite=Lax au cookie de session et
régénérer l'identifiant à la connexion.
Références : OWASP, gestion de session ; documentation MDN sur les cookies.Remarquez le lien avec un autre constat : montrer comment des faiblesses s’enchaînent aide le lecteur à comprendre le risque réel, qui dépasse souvent celui de chaque faille isolée.
Le ton
- Factuel et neutre : on décrit, on ne juge pas les personnes. Une faille est le résultat d’un processus, pas d’une faute individuelle.
- Constructif : l’objectif est l’amélioration, pas la démonstration de compétence.
- Clair : phrases courtes, termes définis la première fois, schémas si utiles.
- Honnête sur les limites : indiquez ce qui n’a pas été testé et pourquoi. Ce qui n’a pas été vu n’est pas forcément sain.
Gérer le rapport en sécurité
- Transmission par un canal chiffré (jamais par une messagerie non protégée avec une pièce jointe en clair).
- Numérotation de version et suivi des modifications.
- Durée de conservation convenue avec le client, puis destruction des preuves et données de test.
- Distribution limitée aux personnes autorisées.
Astuce
Faites relire votre rapport par quelqu’un qui n’a pas fait l’audit. S’il ne comprend pas une fiche, ou ne sait pas par où commencer la correction, c’est que la fiche est à reprendre.
À vous de jouer
Passez de votre carnet à des fiches de rapport.
- Relisez trois constats de votre carnet (par exemple une faille d’authentification, une injection ou un XSS, un défaut de configuration).
- Réécrivez chacun selon le modèle de fiche : identifiant, titre précis, éléments concernés, description, reproduction, preuve, impact, recommandation.
- Ajoutez dans chacun un lien (« voir aussi le constat n° … ») s’ils s’enchaînent.
- Rédigez un brouillon de synthèse de gestion en cinq phrases, sans jargon.
Voir une solution
Exemple de synthèse : « Cet audit, réalisé dans un laboratoire d’entraînement, a porté sur une application de boutique en ligne. Quatorze constats ont été relevés, dont trois de gravité élevée : une injection SQL, un XSS stocké et un défaut de contrôle d’accès. Ces failles permettraient à un attaquant d’accéder aux données d’autres utilisateurs. Les corrections principales sont connues et relativement simples à appliquer. Nous recommandons de traiter en priorité les trois constats les plus graves, puis de mettre en place des tests de sécurité réguliers. » Les chiffres de l’exemple sont purement illustratifs : les vôtres proviennent de votre carnet.
À retenir
- Le rapport transforme un travail technique en décisions et en corrections : il s’adresse à des décideurs et à des techniciens.
- Structure : synthèse, périmètre, méthodologie, tableau de constats, fiches détaillées, points positifs, plan d’action.
- Un bon constat est précis, reproductible, prouvé par la preuve minimale, d’impact crédible, avec une recommandation réaliste.
- Le ton est factuel et constructif ; les limites du test sont indiquées honnêtement.
- Le rapport est un document sensible : transmission chiffrée, version, distribution limitée.
Reste à savoir par où commencer la correction. C’est le rôle de la priorisation, et des scores de gravité : la leçon suivante.