Services Stack Expérience Me contacter
Sécurité

Audit de sécurité web : ma méthode pour couvrir l'OWASP Top 10

Par Benjamin Manguet · 20 mars 2026 · 5 min de lecture

OWASPAudit

Introduction : pourquoi faire un audit de sécurité

Un site web mis en production n’est jamais figé. Les dépendances évoluent, les configurations dérivent, de nouvelles fonctionnalités introduisent de nouveaux vecteurs d’attaque. Pourtant, la sécurité est souvent traitée comme une case à cocher lors de la mise en ligne, puis oubliée.

Un audit de sécurité applicative régulier permet de détecter les vulnérabilités avant qu’elles ne soient exploitées. Ce n’est pas réservé aux grandes entreprises : un site WordPress mal maintenu, une API sans authentification correcte, un formulaire de contact vulnérable aux injections — les cibles faciles sont légion.

Voici la méthodologie que j’ai développée au fil de mes audits, structurée autour du référentiel OWASP Top 10.

Le référentiel OWASP Top 10

L’OWASP (Open Web Application Security Project) publie régulièrement le Top 10, une liste des vulnérabilités web les plus critiques. La version 2021 comprend :

  1. A01 — Broken Access Control : accès non autorisé à des ressources protégées
  2. A02 — Cryptographic Failures : données sensibles mal chiffrées ou transmises en clair
  3. A03 — Injection : SQL, NoSQL, LDAP, commandes OS — tout ce qui concatène des données non filtrées
  4. A04 — Insecure Design : absence de modélisation des menaces dès la conception
  5. A05 — Security Misconfiguration : configurations par défaut, headers manquants, erreurs verboses
  6. A06 — Vulnerable and Outdated Components : dépendances avec des CVE connues non corrigées
  7. A07 — Identification and Authentication Failures : mots de passe faibles, sessions mal gérées
  8. A08 — Software and Data Integrity Failures : pipelines CI/CD non sécurisés, désérialisation non sûre
  9. A09 — Security Logging and Monitoring Failures : absence de logs exploitables pour détecter les incidents
  10. A10 — Server-Side Request Forgery (SSRF) : l’application fait des requêtes vers des ressources internes à la demande d’un attaquant

Ma méthodologie : passive d’abord, active ensuite

Je divise systématiquement mes audits en deux phases.

Phase passive (reconnaissance)

Sans envoyer de requêtes anormales, je collecte le maximum d’informations :

  • Analyse des headers HTTP (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
  • Vérification de la configuration TLS (version, ciphers, certificat)
  • Lecture du fichier robots.txt et des métadonnées HTML
  • Recherche de fichiers exposés (.git, .env, backup.zip, phpinfo.php)
  • Consultation des bases de données CVE pour les technologies identifiées

Phase active (tests)

Une fois la reconnaissance terminée, je passe aux tests actifs — toujours avec l’accord écrit du client :

  • Fuzzing des paramètres GET/POST pour détecter les injections
  • Tests d’authentification et de gestion des sessions
  • Vérification des contrôles d’accès (IDOR, escalade de privilèges)
  • Tests CORS et CSRF

Les outils de mon arsenal

Headers HTTP et TLS

SecurityHeaders.com donne un score immédiat sur la qualité des headers HTTP. SSL Labs analyse en profondeur la configuration TLS et détecte les ciphers obsolètes ou les protocoles anciens (TLS 1.0/1.1).

OWASP ZAP

OWASP ZAP (Zed Attack Proxy) est le couteau suisse de l’audit web. Il intercepte le trafic, effectue des scans automatiques et permet des tests manuels poussés. Je l’utilise principalement en mode “Active Scan” sur les environnements de test :

docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://target.example.com \
  -r rapport_zap.html

Nikto

Nikto est un scanner de vulnérabilités web rapide, idéal pour détecter les problèmes de configuration courants : fichiers sensibles exposés, versions de serveur révélées, options HTTP dangereuses.

nikto -h https://target.example.com -output nikto_report.txt

WPScan pour WordPress

Pour les sites WordPress, WPScan est incontournable. Il détecte les plugins vulnérables, les thèmes obsolètes et les utilisateurs énumérables :

wpscan --url https://target.example.com --enumerate vp,vt,u

Priorisation des vulnérabilités

Toutes les vulnérabilités ne se valent pas. J’utilise le système de scoring CVSS (Common Vulnerability Scoring System) pour prioriser :

  • Critique (9-10) : à corriger immédiatement (injection SQL, RCE, contournement d’authentification)
  • Haute (7-8.9) : à corriger dans la semaine (XSS stocké, IDOR, SSRF)
  • Moyenne (4-6.9) : à planifier dans le sprint suivant (headers manquants, informations divulguées)
  • Faible (0-3.9) : à noter et corriger lors de la prochaine maintenance

Je prends également en compte la faisabilité d’exploitation : une vulnérabilité théorique difficile à exploiter en conditions réelles est moins prioritaire qu’une faille triviale mais sur un endpoint critique.

Rapport et suivi

Le rapport d’audit est structuré en trois parties :

  1. Résumé exécutif : niveau de risque global, points forts, points critiques — lisible par un non-technicien
  2. Détail des vulnérabilités : description, preuve de concept (captures d’écran), score CVSS, recommandations précises
  3. Plan de remédiation : liste priorisée des actions à mener, classées par effort et impact

Je propose systématiquement un re-test deux à quatre semaines après la livraison du rapport, pour vérifier que les corrections ont bien été appliquées et qu’elles n’ont pas introduit de nouvelles failles.

Conclusion

Un audit OWASP Top 10 n’est pas une garantie d’invulnérabilité, mais c’est une base solide pour identifier les risques les plus courants et les plus exploités. La sécurité est un processus continu, pas un état final.

Si vous souhaitez faire auditer votre application web ou site WordPress, n’hésitez pas à me contacter. J’interviens en Charente-Maritime et à distance sur toute la France.