Chaque audit web que je fais suit la même méthodologie. Pas par rigidité, mais parce qu'une checklist structurée évite d'oublier des vecteurs d'attaque. Cette checklist est basée sur l'OWASP Web Security Testing Guide (WSTG) que j'ai adaptée à ma pratique. Voici les 47 points que je vérifie systématiquement.
Phase 1 : Reconnaissance (12 points)
La reconnaissance est la phase la plus importante. Plus tu connais ta cible avant de la toucher, plus tes tests seront ciblés et efficaces.
Reconnaissance passive (points 1-6)
- Collecte DNS complète (A, AAAA, MX, TXT, NS, CNAME, SOA)
- Énumération de sous-domaines via Certificate Transparency logs
- Analyse WHOIS actuel et historique
- Recherche de fuites de code sur GitHub, GitLab, Pastebin
- Identification des technologies via headers HTTP et signatures
- Recherche d'endpoints dans Wayback Machine et Google Cache
Reconnaissance active (points 7-12)
- Scan de ports TCP (top 1000) et identification des services
- Fuzzing de répertoires et fichiers (dirsearch, ffuf)
- Détection du WAF et de ses règles
- Identification du framework backend (Express, Django, Spring...)
- Mapping des API endpoints via documentation ou fuzzing
- Identification des mécanismes d'authentification
Phase 2 : Authentification et sessions (10 points)
Authentification (points 13-18)
- Test de brute force sur le login (rate limiting présent ?)
- Test de credential stuffing avec des listes connues
- Vérification de la politique de mots de passe (longueur, complexité)
- Test de l'enum d'utilisateurs via les messages d'erreur
- Vérification du mécanisme de reset de mot de passe
- Test de bypass de l'authentification 2FA si présente
Sessions (points 19-22)
- Analyse des tokens de session (entropie, prédictibilité)
- Test de fixation de session
- Vérification de l'invalidation de session au logout
- Test de session concurrent (même user, deux navigateurs)
Phase 3 : Injection (8 points)
Les injections restent le vecteur le plus critique. Je teste chaque paramètre d'entrée — GET, POST, headers, cookies.
- SQL injection (error-based, blind boolean, blind time-based) sur chaque paramètre
- NoSQL injection ($gt, $ne, $regex, $where) si MongoDB détecté
- XSS réfléchi sur les paramètres d'URL et les champs de recherche
- XSS stocké sur les champs de formulaire persistés (commentaires, profil)
- Command injection sur les paramètres qui interagissent avec le système
- SSTI (Server-Side Template Injection) si un moteur de template est détecté
- LDAP injection si un annuaire LDAP est utilisé
- XPath injection si du XML est traité côté serveur
Phase 4 : Contrôle d'accès (7 points)
Les failles de contrôle d'accès sont les plus courantes selon l'OWASP Top 10 2021. Je crée toujours deux comptes de test pour vérifier l'isolation.
- IDOR sur chaque endpoint avec un ID dans l'URL ou le body
- Escalade de privilèges horizontale (accès aux données d'un autre user du même rôle)
- Escalade de privilèges verticale (accès aux fonctions admin)
- Bypass de contrôle d'accès via manipulation de headers (X-Forwarded-For, X-Original-URL)
- Test d'accès direct aux fichiers uploadés sans authentification
- Vérification des permissions sur les endpoints API non documentés
- Test de force browsing sur les répertoires sensibles (/admin, /debug, /api/internal)
Phase 5 : Configuration et infrastructure (5 points)
- Vérification des headers de sécurité (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
- Détection de fichiers sensibles exposés (.env, .git, backup.sql, phpinfo)
- Vérification de la configuration TLS (version, cipher suites, certificat)
- Test de CORS misconfiguration (Origin: null, Origin: attacker.com)
- Vérification des messages d'erreur (stack traces exposées en production ?)
Phase 6 : Logique métier (5 points)
Les failles de logique métier sont les plus difficiles à détecter avec des outils automatisés. Elles nécessitent une compréhension du fonctionnement de l'application.
- Test de manipulation de prix (modifier le montant dans la requête de paiement)
- Test de race condition sur les opérations critiques (double spending, double vote)
- Bypass des limites métier (quantité négative, coupon utilisé deux fois)
- Test de workflow bypass (sauter des étapes dans un processus multi-étapes)
- Vérification de la validation côté serveur (pas seulement côté client)
Comment j'utilise cette checklist
Je ne fais pas les 47 points sur chaque audit. La reconnaissance (phase 1) est toujours complète — c'est elle qui oriente le reste. Ensuite, je priorise en fonction de ce que j'ai trouvé. Si l'app utilise des JWT, je passe plus de temps sur l'authentification. Si elle a beaucoup de formulaires, je me concentre sur les injections. Si elle a des rôles utilisateur, je pousse sur le contrôle d'accès.
Un audit web complet prend entre 3 et 5 jours selon la taille de l'application. La checklist me garantit de ne rien oublier, mais l'expérience me dit où creuser plus profond.
Le rapport
Chaque finding est documenté avec : la description de la vulnérabilité, les étapes de reproduction, la preuve de concept (screenshot ou requête cURL), le score CVSS, l'impact business, et la recommandation de correction avec un exemple de code.
Le rapport est structuré par sévérité (critique, haut, moyen, bas, informatif) et inclut un résumé exécutif pour les non-techniques. C'est souvent le résumé exécutif que le client lit en premier — il doit être clair et actionnable.
Une checklist ne remplace pas l'intuition d'un pentester. Mais elle garantit que tu ne rates pas les basiques pendant que tu cherches les failles exotiques.