À quoi ressemble un rapport de pentest ?

Personne ne devrait acheter un audit sans savoir à quoi ressemble le livrable. Cette page reprend la structure exacte du PDF que nous remettons en fin de mission : mêmes sections, même niveau de détail. Seul le contenu change, puisqu'il est ici recomposé et anonymisé.

Demander un devis

Un rapport lu par deux personnes qui ne cherchent pas la même chose.

Un rapport d'audit a deux lecteurs, et ils n'ouvrent pas le document pour les mêmes raisons. La direction veut savoir ce qu'elle risque, combien de temps elle a, et par quoi commencer. L'équipe technique veut le chemin exact, la requête à rejouer et la ligne à corriger. Un rapport qui ne parle qu'à l'un des deux finit dans un tiroir.

C'est pour ça que la synthèse exécutive est écrite sans jargon, avec un lexique quand un terme ne peut pas être évité, et que le détail technique vient après, complet, avec les requêtes brutes. Les deux vivent dans le même document : personne n'a besoin de demander la version longue.

La sévérité, elle, n'est pas un score sorti d'un outil. Chaque vulnérabilité porte un CVSS vectorisé, mais la priorité tient compte de ce que la faille permet chez vous. Une critique sur un environnement de préproduction isolé ne se traite pas comme une élevée sur le service qui porte vos paiements.

Les huit sections, dans l'ordre.

Le sommaire est toujours le même, quelle que soit la mission. Vous savez où chercher avant d'avoir ouvert le document.

Cadre de l'intervention

La cible exacte, l'autorisation écrite qui couvre le test, les dates, la durée, la méthode et l'outillage employés. On y trouve aussi une déclaration de ce qui a été touché : comptes de test créés puis supprimés, modifications réversibles, données de tiers masquées. Rien n'est laissé derrière.

Synthèse exécutive

Ce qui est bien protégé, ce qui pose problème, les risques principaux et l'ordre d'action recommandé. Écrite pour être lue par une direction, sans bagage technique, avec un lexique des termes qui ne peuvent pas être traduits.

Synthèse des vulnérabilités

Le tableau récapitulatif : un numéro, une gravité, le composant touché, la vulnérabilité, l'impact et le statut. Une page pour tout voir, et le point d'entrée vers le détail.

Détail des vulnérabilités

Une fiche par faille. Gravité et CVSS vectorisé, description précise du défaut, preuve de reproduction avec les requêtes brutes, impact démontré, prérequis d'exploitation, remédiation numérotée et statut.

Points positifs

Ce qui tient. La plupart des rapports ne listent que les problèmes, ce qui donne une image fausse d'un système parfois globalement sain. Savoir ce qui est déjà solide évite de remettre en cause ce qui n'a pas à l'être.

Recommandations non bloquantes

Les durcissements qui n'entrent pas dans la liste des vulnérabilités mais qui réduisent la surface : en-têtes, configuration, journalisation, rate-limit. Séparés du reste pour ne pas noyer les priorités.

Retest

Le résultat de la reprise des tests après vos correctifs, faille par faille, avec la date et ce qui a été constaté. C'est la section qui transforme une liste de problèmes en un dossier clos, et elle est ajoutée dans une version 1.1 du rapport.

Annexes

Les requêtes complètes et les preuves, rassemblées à part pour que le corps du rapport reste lisible. Les captures et les accès sensibles sont conservés séparément et transmis par canal chiffré, jamais collés dans le document.

Le tableau de synthèse.

Extrait recomposé. Chaque ligne renvoie à une fiche détaillée dans la section suivante du rapport.

Exemple de tableau de synthèse des vulnérabilités
N°	Gravité	Composant	Vulnérabilité	Impact
4.1	Critique	`api.exemple.fr/v1/orders/{id}`	Contrôle d'accès objet absent (BOLA) sur la lecture des commandes	Lecture de la commande de n'importe quel client à partir de son seul identifiant
4.2	Élevée	`api.exemple.fr/v1/account`	Champ `role` accepté en écriture (mass assignment)	Un compte standard se promeut administrateur en une requête
4.3	Élevée	www.exemple.fr, réinitialisation	Jeton de réinitialisation sans expiration	Un lien intercepté reste utilisable des semaines plus tard
4.4	Moyenne	www.exemple.fr, connexion	Aucune limitation du nombre de tentatives d'authentification	Rejeu à grande échelle d'identifiants issus de fuites publiques

Une vulnérabilité, en détail.

Voici la fiche complète de la ligne 4.1 du tableau ci-dessus. C'est le niveau de détail que reçoit votre équipe technique, pour chaque faille.

4.1 Lecture des commandes de tout client sans autorisation

Critique

Gravité Critique, CVSS 3.1 : 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)

Composant GET /v1/orders/{id} sur api.exemple.fr

Description L'API vérifie que l'appelant est authentifié, mais pas que la commande demandée lui appartient. L'identifiant est un entier séquentiel transmis dans l'URL. Un client authentifié qui remplace son propre identifiant par celui d'un autre reçoit la commande complète : nom, adresse de livraison, téléphone, lignes de commande et montant. Le serveur répond 200 dans les deux cas.

Preuve de reproduction

GET /v1/orders/4172 HTTP/1.1
Host: api.exemple.fr
Authorization: Bearer <jeton du compte de test>

HTTP/1.1 200 OK
{"id":4172,"customer":"compte de test","total":"149.90", ...}

GET /v1/orders/4173 HTTP/1.1
Host: api.exemple.fr
Authorization: Bearer <le même jeton>

HTTP/1.1 200 OK
{"id":4173,"customer":"un autre client","total":"318.00", ...}

Impact Impact démontré en lecture. Les identifiants étant séquentiels, l'énumération est triviale et automatisable : l'intégralité de l'historique de commandes est récupérable avec un seul compte client légitime. Les données concernées sont des données personnelles au sens du RGPD (article 4) ; une exploitation avérée constituerait une violation à notifier à la CNIL sous 72 heures (article 33). Aucune écriture n'a été tentée.

Prérequis Un compte client standard, créé librement depuis le site. Aucune élévation de privilège préalable, aucune interaction d'une victime.

Remédiation

Vérifier côté serveur, sur cette route et sur toutes les routes qui prennent un identifiant d'objet, que l'objet demandé appartient bien à l'utilisateur de la session.
Traiter le contrôle d'accès dans une couche commune plutôt que route par route, pour que l'oubli ne soit plus possible.
Remplacer les identifiants séquentiels par des identifiants non devinables (UUID v4). Mesure de défense en profondeur, pas un correctif à elle seule.
Auditer les journaux d'accès à la recherche d'énumérations passées sur cette route.

Statut Corrigé par le client, puis vérifié au retest. Le retest est inclus dans la mission : aucune vulnérabilité ne reste au statut « corrigé » sur notre seule parole.

Ce que le rapport ne contient pas.

Autant que ce qu'il contient, ce qui en est volontairement absent fait partie de l'engagement.

Aucune donnée réelle de vos clients. Les preuves sont tronquées et masquées, les jeux de données extraits ne sont jamais recopiés dans le document.
Aucun identifiant ni jeton actif. Ce qui doit être transmis passe par un canal chiffré, séparément du rapport. Et si de vrais identifiants de vos comptes ont fuité et que nous tombons dessus pendant la mission, nous vous prévenons aussitôt pour que vous les changiez, sans attendre la remise.
Aucun remplissage. Pas de sortie brute d'outil recopiée, pas de vulnérabilité théorique non vérifiée pour gonfler le total.
Aucune diffusion. Le rapport vous appartient ; nous ne le partageons avec personne et nous ne citons jamais le nom d'un client.

Comment se déroule une mission

Un rapport comme celui-ci, sur votre application.

Décrivez-nous le périmètre et nous vous répondons avec un cadrage et un devis. Premier échange sans engagement, confidentialité totale.

Demander un devis Combien ça coûte