Rapport de Pentest

Le rapport est la livrable principale d’un pentest. Un test technique excellent mal reporté a peu de valeur. Le rapport doit permettre à deux publics différents — les décideurs et les équipes techniques — d’agir.

Structure générale§

1. Page de titre et informations projet
2. Résumé exécutif (Executive Summary)
3. Portée et méthodologie
4. Résumé des résultats (tableau de bord)
5. Findings détaillés
6. Recommandations
7. Annexes (preuves, scans bruts, outils utilisés)

1. Informations projet§

Client          : Entreprise XYZ
Scope           : app.xyz.com, api.xyz.com, 10.0.0.0/24
Type de test    : Boîte grise / Black box / White box
Dates           : 2026-01-15 au 2026-01-25
Testeur(s)      : Prénom NOM, Prénom NOM
Version rapport : 1.0 (Brouillon) / 2.0 (Final)
Classifiction   : CONFIDENTIEL

2. Résumé exécutif§

Le résumé exécutif doit être lisible par un directeur non-technique en 2 minutes. Pas de jargon.

Structure :

Objectif du test
  → "XYZ Corp a mandaté [société] pour évaluer la sécurité de son
    application web client-facing..."

Résultat global en une phrase
  → "L'application présente un niveau de risque ÉLEVÉ avec une vulnérabilité
    critique permettant l'accès aux données de tous les utilisateurs."
    ou
  → "Aucune vulnérabilité critique n'a été identifiée durant la période de test."

Points saillants (3-5 bullet points)
  → Vulnérabilité la plus grave en une ligne
  → Tendance générale (ex: contrôles d'accès insuffisants)
  → Comparaison avec le test précédent (si applicable)

Recommandation principale
  → Action prioritaire à prendre immédiatement

Tonalité : factuelle et non alarmiste. Éviter "le système est vulnérable à tout"

3. Portée et méthodologie§

Portée incluse :
  - https://app.xyz.com (authentification, dashboard, API)
  - Plage IP : 10.0.0.1 - 10.0.0.50
  - Applications mobiles : xyz-app v2.3 (iOS, Android)

Portée exclue :
  - Tiers (Stripe, AWS SaaS)
  - Attaques par déni de service
  - Ingénierie sociale

Autorisations :
  - Autorisation signée le 2026-01-10 (référence : AUTH-2026-001)
  - Fenêtre de test : jours ouvrés 9h-18h
  - Contact client d'urgence : Jean Dupont, 06 XX XX XX XX

Méthodologie :
  OWASP Testing Guide v4.2, PTES (Penetration Testing Execution Standard)
  Phases : reconnaissance, scan, exploitation, post-exploitation, reporting

4. Tableau de bord des résultats§

Résumé par sévérité :

┌────────────┬───────┬─────────────────────────────────┐
│ Sévérité   │ Nb    │ Statut                          │
├────────────┼───────┼─────────────────────────────────┤
│ Critique   │  2    │ Correction immédiate requise    │
│ Élevée     │  4    │ Correction sous 30 jours        │
│ Moyenne    │  7    │ Correction sous 90 jours        │
│ Faible     │  5    │ À corriger lors de la prochaine │
│            │       │ itération                       │
│ Info       │  3    │ Observation, pas d'action requise│
└────────────┴───────┴─────────────────────────────────┘

Total : 21 findings

5. Finding détaillé — structure§

Chaque vulnérabilité suit le même format :

ID              : FIND-001
Titre           : Injection SQL dans le paramètre de recherche
Sévérité        : Critique
Score CVSS v3.1 : 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE             : CWE-89 (Improper Neutralization of Special Elements)
Système affecté : https://app.xyz.com/search

Description
  Une injection SQL a été identifiée dans le paramètre `query` de l'endpoint
  de recherche. L'absence de paramétrage des requêtes permet à un attaquant non
  authentifié d'extraire l'intégralité de la base de données.

Impact
  - Divulgation de toutes les données utilisateurs (emails, hashes de mots de passe)
  - Potentiel d'authentification bypass (voir FIND-002)
  - Risque de modification ou suppression des données

Preuve (Proof of Concept)
  Requête envoyée :
    GET /search?query=test' OR '1'='1 HTTP/1.1
    Host: app.xyz.com

  Réponse :
    HTTP/1.1 200 OK
    [Contenu de toute la table users]

  Capture d'écran : [Annexe A, Figure 1]

Étapes de reproduction
  1. Naviguer vers https://app.xyz.com/search
  2. Saisir le payload suivant dans le champ de recherche :
     test' UNION SELECT username, password, email FROM users--
  3. Constater le retour des données utilisateurs dans la réponse

Recommandation
  - Court terme : utiliser des requêtes paramétrées (PreparedStatement en Java,
    PDO en PHP, SQLAlchemy avec bind parameters en Python)
  - Long terme : mettre en place un WAF en défense en profondeur
  - Vérifier toutes les autres requêtes SQL de l'application

Référence
  OWASP SQL Injection — https://owasp.org/www-community/attacks/SQL_Injection
  CWE-89

6. Recommandations — structure§

Court terme (0-30 jours) — Vulnérabilités critiques et élevées
  Action urgente : décrire précisément ce qui doit être fait

Moyen terme (30-90 jours) — Vulnérabilités moyennes + hardening
  Actions planifiables

Long terme (90+ jours) — Architecture, processus, formation
  Améliorations structurelles

Tableau de remédiation§

Scoring des vulnérabilités§

CVSS v3.1§

Vecteur de base :
AV (Attack Vector)    : N (Network) / A (Adjacent) / L (Local) / P (Physical)
AC (Attack Complexity): L (Low) / H (High)
PR (Privileges Required): N (None) / L (Low) / H (High)
UI (User Interaction) : N (None) / R (Required)
S  (Scope)            : U (Unchanged) / C (Changed)
C  (Confidentiality)  : N / L / H
I  (Integrity)        : N / L / H
A  (Availability)     : N / L / H

Score : 0.0 - 3.9 (Faible) / 4.0 - 6.9 (Moyen) / 7.0 - 8.9 (Élevé) / 9.0 - 10.0 (Critique)

Calculateur : https://www.first.org/cvss/calculator/3.1

Sévérité contextuelle§

Le score CVSS est une base objective, mais le contexte client ajuste la sévérité finale :

Critique → Élevée si :
  - La donnée exposée est publique ou anonyme
  - Des contrôles compensatoires existent (WAF, réseau isolé)

Élevée → Critique si :
  - L'application traite des données de santé ou financières
  - L'exploitation est triviale et déjà publique (PoC en ligne)
  - Le finding combiné avec un autre mène à un impact plus grave

7. Annexes§

Annexe A : Captures d'écran numérotées (preuves visuelles)
Annexe B : Logs bruts et payloads utilisés
Annexe C : Sortie des outils automatisés (Nmap, Nuclei, Burp)
Annexe D : Liste complète des URLs testées
Annexe E : Glossaire des termes techniques

Bonnes pratiques rédactionnelles§

Être factuel et reproductible
  → Chaque finding doit être reproductible par un tiers à partir des étapes décrites

Ne pas exagérer / ne pas minimiser
  → La sévérité doit refléter l'impact réel, pas impressionner ou rassurer le client

Proposer des solutions concrètes
  → "Utiliser des requêtes paramétrées" > "Corriger l'injection SQL"

Séparer observation et exploitation
  → Distinguer ce qui a été identifié comme vulnérable de ce qui a effectivement été exploité

Screenshots avec annotations
  → Flèches, encadrés, légendes — le lecteur ne doit pas chercher la partie intéressante

Respecter la confidentialité
  → Anonymiser les noms d'utilisateurs réels dans les preuves si possible
  → Chiffrer le rapport (PDF protégé par mot de passe ou livraison sécurisée)

Numérotation et références croisées
  → FIND-001 référencé dans les recommandations → le lecteur navigue facilement

Checklist avant livraison§

Général :
✓ Date de livraison et version clairement indiqués
✓ Périmètre testé vs périmètre non testé documenté
✓ Aucune donnée client réelle dans les exemples (ou anonymisée)
✓ Rapport chiffré ou transmis de manière sécurisée

Contenu :
✓ Chaque finding a : titre, sévérité, description, impact, PoC, remédiation
✓ Les étapes de reproduction sont testées et fonctionnelles
✓ Le résumé exécutif est compréhensible sans connaissance technique
✓ Les recommandations sont priorisées et actionnables

Technique :
✓ Tous les outils et versions utilisés sont listés
✓ Les faux positifs ont été éliminés (vérification manuelle)
✓ Les scores CVSS sont justifiés
✓ Les références (CWE, OWASP) sont correctes