Rédiger un rapport de vulnérabilité qui est pris au sérieux

Trouver une faille n'est que la moitié du travail. L'autre moitié, souvent négligée par les débutants, est de la faire comprendre. Un rapport brouillon est rejeté, ignoré ou mal classé, même quand la faille est réelle. À l'inverse, un rapport clair, mesuré et reproductible gagne le respect des équipes et, avec le temps, ouvre des portes. Cette leçon vous apprend à rédiger un rapport professionnel, et vous en fait écrire un.

Se mettre à la place du lecteur

Trois lecteurs, trois besoins :

• L'analyste de tri reçoit des dizaines de rapports par jour. Il veut comprendre en 30 secondes de quoi il s'agit et si c'est crédible.
• Le développeur doit corriger. Il lui faut la reproduction exacte, la cause probable et une piste de correction.
• Le responsable décide de la priorité. Il veut l'impact en termes concrets : quelles données, combien de personnes, quel risque pour l'activité.

Un bon rapport sert les trois, dans cet ordre : résumé, preuve, correction.

La structure d'un bon rapport

1. Un titre précis

Il dit quoi et où. Comparez « Faille grave sur le site » et « Contrôle d'accès défaillant sur GET /api/commandes/{id} : lecture des commandes d'un autre client ». Le second est triable et vérifiable.

2. Un résumé

Deux ou trois phrases : la nature de la faille, où elle se trouve, ce qu'elle permet. Un lecteur pressé doit pouvoir s'arrêter là et avoir compris l'essentiel.

3. La gravité et l'impact

Expliquez ce qui peut arriver, à qui, et à quelles conditions. Évitez le sensationnel : un rapport crédible distingue ce qui a été démontré de ce qui est possible. Beaucoup de programmes utilisent un système de notation de la gravité (comme le CVSS) ; vous pouvez proposer un niveau, en justifiant, mais la décision finale appartient à l'organisation.

4. Les prérequis

Quel type de compte faut-il ? Y a-t-il des conditions particulières (navigateur, configuration, droits) ?

5. Les étapes de reproduction

Une liste numérotée, simple, que quelqu'un d'autre peut suivre sans deviner. Chaque étape est une action et un résultat attendu. Indiquez l'environnement et la date. La règle : « si je suis ces étapes un jour de lundi matin, avec un café, j'obtiens le même résultat ».

6. Les preuves

Captures d'écran annotées, extraits de requêtes et de réponses (avec les données sensibles masquées), éventuellement une courte vidéo. Les preuves doivent être minimales : suffisantes pour démontrer, jamais une copie massive de données.

7. La cause probable et la recommandation

Proposez une correction ou une piste, avec prudence : vous ne connaissez pas toujours le code interne. Citez des références utiles : catégories de l'OWASP (owasp.org), identifiants de faiblesses, documentation officielle.

8. Les informations complémentaires

Limites de votre test, ce que vous n'avez pas vérifié, éventuels effets de bord observés, et votre disponibilité pour confirmer la correction.

Un exemple complet (fictif, en laboratoire)

Voici un modèle de rapport, rédigé pour une application web d'entraînement hébergée dans un laboratoire :

Titre. Contrôle d'accès défaillant sur la consultation des commandes : un client peut lire les commandes d'un autre client.

Résumé. Le point d'accès GET /api/commandes/{id} renvoie la commande demandée sans vérifier qu'elle appartient à l'utilisateur connecté. Un utilisateur authentifié peut donc consulter les commandes d'autres clients en modifiant l'identifiant dans l'adresse.

Gravité proposée. Élevée. Impact : exposition de noms, adresses et contenus de commandes de tous les clients. Conditions : disposer d'un compte client ordinaire. Non démontré : l'accès en écriture n'a pas été testé.

Environnement. Application de laboratoire, version de test du 12 mars, deux comptes de test créés pour l'occasion.

Étapes. 1. Se connecter avec le compte de test A et créer la commande n° 1001. 2. Se connecter avec le compte de test B et créer la commande n° 1002. 3. Avec le compte A, demander GET /api/commandes/1002. 4. Observer : la réponse est un code 200 contenant les informations de la commande du compte B.

Preuves. Capture de la requête et de la réponse avec les champs personnels masqués (pièce jointe 1).

Recommandation. Vérifier côté serveur que l'identifiant du client de la commande correspond à celui de l'utilisateur authentifié ; renvoyer une réponse « introuvable » dans le cas contraire. Centraliser ce contrôle pour tous les points d'accès similaires. Référence : catégorie « contrôle d'accès défaillant » de l'OWASP.

Limites. Aucun accès à des données autres que celles de mes deux comptes de test. Je reste disponible pour valider la correction.

Remarquez ce qui fait la qualité de cet exemple : un titre précis, une reproduction que n'importe qui peut rejouer avec deux comptes créés par soi-même, des preuves minimales, un impact nuancé (« non démontré : écriture »), une recommandation concrète.

Les erreurs de débutant

• Le rapport « fourre-tout » : plusieurs failles dans un seul rapport. Un rapport par faille, pour qu'il puisse être trié, corrigé et récompensé séparément.
• L'exagération : « un attaquant pourrait prendre le contrôle de toute l'entreprise » quand on a seulement trouvé une fuite mineure. Cela détruit la crédibilité.
• L'absence de reproduction : « il y a une faille quelque part » ne peut pas être traité.
• Le rapport d'outil brut : coller la sortie d'un scanner sans vérification est la première cause de rejet. Un scanner produit des hypothèses, pas des preuves.
• Le ton agressif ou exigeant : « payez-moi ou je publie ». C'est contraire à l'éthique et potentiellement illégal.
• L'excès de données : joindre des données réelles d'utilisateurs ou des identifiants complets. Masquez et minimisez.
• L'oubli de relire : fautes, captures illisibles, étapes incomplètes. Relisez comme si vous étiez le développeur.

Accepter les retours

Votre rapport sera parfois refusé, requalifié à une gravité moindre, ou jugé « doublon ». Répondez avec calme et professionnalisme : demandez des précisions, apportez des éléments supplémentaires si vous pensez qu'une information a été mal comprise, remerciez pour la réponse. Un désaccord courtois se règle souvent en une réponse ; une dispute publique abîme durablement une réputation. La communauté est petite et les gens se souviennent.

Le même savoir-faire, en entreprise

Dans un audit professionnel, le rapport est le livrable principal. Il comprend en plus une synthèse pour la direction (non technique, une page), le périmètre et la méthodologie, la liste des constats classés par gravité et un plan d'action. Vous utiliserez la même structure que dans cette leçon : constat, risque, preuve, recommandation, priorité. Les clients lisent d'abord la synthèse et la liste des priorités : soignez-les.

À vous de jouer

Voici un rapport médiocre reçu pour une application d'entraînement :

« Votre site est très vulnérable. Un hacker peut tout voler. J'ai utilisé un scanner qui a trouvé plein de problèmes (voir pièce jointe de 400 pages). Il faut corriger rapidement, sinon je serai obligé de rendre cela public. »

Listez au moins cinq défauts, puis réécrivez le début du rapport (titre, résumé en deux phrases) pour une faille imaginaire : « la page de réinitialisation du mot de passe révèle si une adresse de courriel est enregistrée ».