Conduire un pentest web consiste à reproduire méthodiquement les actions d'un attaquant sur une application pour en révéler les vulnérabilités avant qu'elles ne soient exploitées. La méthode suit six phases enchaînées, du cadrage initial jusqu'à la remise du rapport, chacune conditionnant la qualité de la suivante.

Cet article détaille chaque phase selon les référentiels OWASP Testing Guide et PTES (Penetration Testing Execution Standard), avec les outils utilisés en pratique et les pièges à éviter.

Phase 1 : Cadrage et règles d'engagement

Aucun test ne commence sans un périmètre écrit et signé. Cette phase définit ce qui peut être touché, ce qui ne peut pas l'être, et les conditions dans lesquelles les tests se déroulent.

  • Périmètre (scope) : liste explicite des domaines, sous-domaines, adresses IP, API endpoints et environnements ciblés. Tout ce qui n'est pas listé est hors scope.
  • Autorisation formelle : lettre de mission ou bon de commande précisant les dates, les techniques autorisées (test non destructif, exploitation contrôlée, social engineering exclu ou inclus) et les coordonnées d'un contact technique côté client.
  • Fenêtres de test : certaines applications critiques nécessitent des tests en dehors des heures de pointe. À préciser en amont.
  • Critères d'arrêt : conditions qui imposent de suspendre les tests : détection par un WAF bloquant les IPs, impact sur la disponibilité, découverte d'une vulnérabilité critique en production.

Un cadrage bâclé produit soit un rapport incomplet, soit un incident en production. C'est la phase la plus sous-estimée.

Phase 2 : Reconnaissance et collecte d'informations

Avant de toucher à l'application, on cartographie ce qui est visible depuis l'extérieur. L'objectif : comprendre la surface d'attaque réelle, pas seulement ce que le client déclare.

Reconnaissance passive (OSINT)

  • Enumération DNS : sous-domaines exposés, enregistrements SPF/DMARC, transferts de zone mal configurés
  • Recherche dans les certificats TLS via crt.sh pour retrouver des sous-domaines non documentés
  • Google Dorks ciblés sur le domaine : fichiers de configuration exposés, erreurs d'application indexées, répertoires ouverts
  • Analyse des headers HTTP publics : technologies serveur, frameworks, CDN utilisés
  • Fuites dans les dépôts Git publics (GitHub, GitLab) : clés API, tokens, fichiers .env commités par erreur

Fingerprinting technique

  • Identification du stack applicatif : langage backend, framework frontend, CMS éventuel, version
  • Analyse des en-têtes de réponse HTTP : Server, X-Powered-By, cookies de session (nom, flags)
  • Détection des composants tiers : librairies JavaScript, polices chargées, pixels de tracking, chaque dépendance externe est un vecteur potentiel

Phase 3 : Cartographie de l'application

On entre ici dans l'application en tant qu'utilisateur (parfois avec un compte fourni par le client) pour recenser exhaustivement les fonctionnalités et les points d'entrée.

  • Crawl automatisé et manuel : parcourir chaque page, formulaire, lien, action JavaScript. Les crawlers automatiques ratent systématiquement les flux initiés par des interactions utilisateur complexes.
  • Inventaire des endpoints API : REST, GraphQL, WebSockets. Attention aux endpoints non documentés accessibles en devinant les routes.
  • Flux d'authentification : inscription, connexion, réinitialisation de mot de passe, OAuth, SSO, 2FA. Chaque étape est un point d'entrée potentiel.
  • Gestion des rôles : différents niveaux d'accès (utilisateur standard, administrateur, invité). Les vulnérabilités d'autorisation apparaissent dans les transitions entre rôles.
  • Paramètres et données entrantes : champs de formulaire, paramètres d'URL, headers HTTP personnalisés, données JSON : tout ce qui est contrôlable par un attaquant.

Phase 4 : Tests ciblés par famille de vulnérabilités

C'est la phase technique centrale. Les tests suivent les catégories OWASP Top 10, complétées par des vérifications spécifiques à la logique métier.

Injections

  • SQL Injection : tests sur tous les paramètres qui interagissent avec une base de données, y compris les paramètres d'ordre de tri, de pagination, et les headers HTTP comme User-Agent ou Referer
  • NoSQL Injection : sur les applications MongoDB ou Elasticsearch, les payloads diffèrent mais le principe est identique
  • SSTI (Server-Side Template Injection) : détection via des payloads mathématiques dans les champs affichés dynamiquement
  • Command Injection : sur les fonctionnalités qui appellent des commandes système (export PDF, traitement d'image, ping)

XSS et injections côté client

  • XSS réfléchi, stocké et DOM-based : les trois variantes ont des impacts différents et des vecteurs d'exploitation distincts
  • Contournement de CSP (Content Security Policy) si une politique est en place

Contrôle d'accès et autorisation

  • IDOR (Insecure Direct Object Reference) : modification des identifiants dans les requêtes pour accéder aux ressources d'un autre utilisateur
  • Escalade de privilèges horizontale et verticale : accéder à des fonctions réservées à un rôle supérieur
  • BOLA sur les APIs : équivalent IDOR pour les endpoints REST et GraphQL

SSRF et interactions serveur

  • Tests SSRF sur les fonctionnalités qui récupèrent des ressources distantes (import d'URL, webhooks, prévisualisation de liens)
  • Sur les applications hébergées sur AWS, une SSRF peut donner accès aux métadonnées EC2 ; voir notre guide sur SSRF et IMDSv2

Logique métier

  • Contournement de processus multi-étapes (commander sans payer, valider sans vérification)
  • Manipulation de valeurs numériques (prix négatifs, quantités invalides)
  • Abus de fonctionnalités légitimes à des fins non prévues

Phase 5 : Exploitation contrôlée et preuves

Identifier une vulnérabilité ne suffit pas : il faut démontrer son impact réel pour que le client comprenne ce qu'un attaquant pourrait effectivement faire.

  • Proof of Concept (PoC) : chaque vulnérabilité exploitée donne lieu à un PoC reproductible : requête HTTP complète, payload utilisé, conditions requises
  • Preuves visuelles : captures d'écran annotées montrant l'exploitation et ses conséquences (données exposées, élévation de privilèges, exécution de code)
  • Chaînage de vulnérabilités : certaines vulnérabilités de criticité modérée deviennent critiques combinées entre elles, par exemple un XSS stocké + un CSRF peut permettre une prise de contrôle de compte
  • Limites de l'exploitation : on arrête avant d'impacter les données de production ou la disponibilité du service. L'objectif est la preuve, pas la destruction.

Phase 6 : Rapport, synthèse et priorisation

Le rapport est le seul livrable tangible du pentest. Un test brillant mal documenté n'a aucune valeur opérationnelle.

Synthèse exécutive

Destinée aux décideurs non techniques : niveau de risque global, nombre de vulnérabilités par criticité, deux ou trois constats majeurs en langage clair, recommandation de priorité de correction.

Détail technique

Pour chaque vulnérabilité :

  • Description précise et localisation (URL, paramètre, endpoint)
  • Score CVSS v3.1 avec justification des métriques
  • Preuve d'exploitation (PoC, captures d'écran, requêtes brutes)
  • Impact potentiel si exploitée par un attaquant réel
  • Recommandation de correction concrète, avec exemples de code si pertinent
  • Références : CVE associées, OWASP, documentation officielle

Plan de remédiation priorisé

Les vulnérabilités sont classées par ordre de priorité de correction selon leur criticité, leur facilité d'exploitation et leur impact métier. Cela permet à l'équipe de développement de traiter en premier ce qui présente le risque le plus élevé.

Conclusion

Un pentest web rigoureux n'est pas une liste de scanners automatiques : c'est une démarche structurée qui combine outils, raisonnement offensif et compréhension du contexte métier. Chaque phase nourrit la suivante, et la qualité du rapport final dépend de la rigueur de toutes les étapes précédentes.

Si vous souhaitez faire réaliser un test d'intrusion web sur votre application, consultez notre offre de pentest web, périmètre adapté à votre stack, rapport à deux niveaux, retest inclus.