Wapiti : scanner open source de vulnérabilités web en boîte noire

Table des matières :

Wapiti en 2026 : ce que fait réellement un scanner « boîte noire »

Wapiti est un scanner open source de vulnérabilités web en boîte noire (DAST) : il ne lit pas votre code, il observe l’application depuis l’extérieur, comme un attaquant. Concrètement, il explore des URL (crawl), identifie des points d’injection (paramètres GET/POST, champs de formulaires, en-têtes…), injecte des charges utiles, puis infère une faille à partir des réponses HTTP (statut, corps, temps de réponse, erreurs SQL, traces…). Cette approche est utile sur des stacks où une partie du risque vient de la surface exposée (routes, modules, endpoints oubliés, pages de debug), ce qui est typiquement le cas des boutiques PrestaShop avec historiques de modules et d’overrides.

Sur le plan conceptuel, Wapiti se cale sur une logique DAST « classique » : (1) découverte (crawler), (2) attaque (modules de tests), (3) reporting (preuves, payloads, URLs). Cela le distingue d’un SAST (analyse statique), d’un scanner de dépendances (SCA/SBOM) ou d’un IDS/WAF. OWASP rappelle d’ailleurs que « The OWASP Top 10 is a standard awareness document for developers and web application security » (OWASP Top 10, https://owasp.org/www-project-top-ten/) : un scanner n’est pas un audit complet, mais un moyen pragmatique d’identifier des classes d’erreurs récurrentes.

Ce que ça implique en pratique : un DAST est très bon pour détecter des failles observables au niveau HTTP, notamment celles qui se manifestent par un reflet, une erreur, un différentiel de temps, ou un changement de comportement. Exemple e-commerce réaliste :

une page de recherche qui reflète un paramètre sans encodage (candidat XSS réfléchi) ;
un endpoint d’export CSV dans un module « back-office » qui accepte des paramètres inattendus (candidat injection) ;
un formulaire d’upload (import produits, logos, factures) qui laisse transiter des extensions ou des types MIME non attendus (candidat upload / LFI en chaîne).

À garder en tête côté PrestaShop : le cœur s’améliore, mais l’écosystème (modules tiers, overrides legacy, endpoints AJAX, webhooks) conserve un profil de risque « long tail ». Wapiti est pertinent pour attraper ce qui fuit au niveau HTTP (XSS réfléchi, injections SQL basiques, inclusions de fichiers, mauvaises configurations, etc.), mais il ne remplacera pas une analyse ciblée des vulnérabilités logiques ni des failles de chaîne d’approvisionnement.

Un point « terrain » en France/UE : si vous testez des environnements contenant des données personnelles, vos captures (rapports, traces HTTP, artefacts CI) peuvent elles-mêmes devenir des données sensibles. La bonne hygiène est de privilégier un staging anonymisé et de limiter le contenu enregistré dans les artefacts (principe de minimisation RGPD), surtout si ces artefacts circulent dans des outils SaaS.

Pour la partie audit structuré (périmètre, niveaux de preuve, priorisation, plan de durcissement), vous aurez plutôt intérêt à coupler avec une démarche décrite dans un audit sécurité (voir par exemple : Audit sécurité PrestaShop : méthodologie, livrables et durcissement).

Installation propre : isoler l’outil et maîtriser la version (Python, OS, réseau)

En 2026, le point dur n’est pas l’installation « qui marche », c’est l’installation reproductible. Wapiti est un outil Python ; l’approche la moins pénible pour éviter de polluer le système est pipx (environnement isolé par outil). Sur une Debian/Ubuntu de build/scan (ou une VM dédiée), on part généralement sur Python 3.11+ :

sudo apt-get update
sudo apt-get install -y pipx python3-venv
pipx ensurepath
pipx install wapiti3
wapiti --version

Deux améliorations simples pour maîtriser réellement la version :

Journaliser la version exacte dans vos logs CI (sortie de wapiti --version, version Python, OS). C’est indispensable quand vous comparez deux scans à 6 mois d’écart.
Geler votre méthode d’installation : pipx + version taggée dans un script, ou une image interne de scan. Le but est d’éviter le « ça marchait hier » parce qu’une dépendance a changé.

Si vous scannez depuis la même machine que vos workloads (mauvaise idée), vous allez vous battre avec des limitations OS : sockets, DNS, NAT, règles iptables, etc. L’idéal reste un runner CI dédié ou une VM de sécurité, avec un egress contrôlé. En environnement conteneurisé, vous pouvez aussi encapsuler Wapiti dans une image interne (non fournie ici) pour garantir la version exacte (hash de dépendances). Ce point rejoint les pratiques « supply chain » abordées dans PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD.

Pré-requis opérationnels avant de lancer un DAST : (a) autorisation (scan uniquement sur des cibles dont vous avez la propriété ou un mandat), (b) environnement staging aussi proche que possible de la prod, (c) fenêtre de tir et rate raisonnables.

Checklist « installation / exécution » qui évite 80% des problèmes :

Résolution DNS et routage vers la cible (VPN, IP allowlist, accès privé).
Identité réseau stable (éviter un scan depuis un laptop nomade).
Timeouts et limites (ne pas laisser un scan tourner indéfiniment).
User-agent explicite et logs côté serveur (pour corréler facilement vos requêtes).
Désactivation des services externes sur staging (SMTP, ERP, transporteurs, PSP) ou bascule vers sandboxes pour éviter des effets de bord.

Sur PrestaShop, le staging doit reproduire le routage (Nginx/Apache), le TLS, le CDN/WAF éventuel, et surtout la même version de modules. Sinon vous scannez un artefact qui ne ressemble à rien. Pour la mise en place d’un staging fidèle, voir : Staging PrestaShop : créer un environnement Docker fidèle à la production.

Crawler, périmètre et bruit : comment éviter un scan inutile (ou dangereux)

Un scan « boîte noire » est d’abord un problème de périmètre. Wapiti va suivre des liens et des formulaires ; si vous le laissez partir sans garde-fous, il peut crawler des pages hors scope (domaines externes, CDN, sous-domaines) ou marteler des endpoints sensibles (recherche, panier, paiement). La stratégie rationnelle : démarrer petit, figer le scope, puis augmenter progressivement la profondeur.

Dans Wapiti, le périmètre se règle via des notions de scope (même domaine / URL de base), de profondeur, et de contraintes sur le nombre de liens/paramètres explorés. Les noms d’options évoluent selon les versions, donc ne copiez pas un blog-post aveuglément : exécutez wapiti --help et verrouillez votre commande dans un script versionné. Une ligne de base réaliste pour une boutique de taille moyenne est : une profondeur limitée, un timeout strict, et un ensemble de modules ciblés (plutôt que « tout »), sinon vous aurez un rapport volumineux rempli de faux positifs.

Approche pratique pour réduire le bruit (et le risque) dès le départ :

Seed list : partez d’une liste de quelques URL pertinentes (home, catégories, fiche produit, recherche, contact, login, pages CMS, endpoints module identifiés). Pour générer une base, sitemap.xml (si disponible) est souvent plus fiable que le crawl intégral — et proche d’une « surface exposée » réelle.
Denylist : excluez explicitement les zones à effets de bord : /panier, /commande, /paiement, endpoints d’annulation/retour, URLs de tracking, etc.
Données de test : si le crawler tombe sur des formulaires (création de compte, inscription newsletter), assurez-vous que les données de test sont isolées (alias email, numéros fictifs).

Le bruit le plus fréquent côté e-commerce : (1) URL paramétrées à l’infini (tri, pagination, filtres), (2) facettes générant des combinaisons quasi infinies, (3) endpoints AJAX et APIs internes. Sur PrestaShop, les facettes et paramètres peuvent exploser le graphe ; c’est exactement le même problème que le budget de crawl SEO, mais vu sous l’angle sécurité. Si vous avez déjà dû contenir les facettes pour Googlebot, vous connaissez le symptôme (voir : Budget de crawl PrestaShop : maîtriser URLs de filtres et facettes). Appliquez la même discipline : exclusions de patterns, limitation de profondeur, seed list d’URL pertinentes.

Dernier point « sécurité » : un scan non borné ressemble vite à un début de DoS applicatif (pics CPU, saturation DB via recherches). Même sur staging, c’est une bonne discipline de monitorer pendant le scan : erreurs 5xx, latence, saturation du pool PHP-FPM, requêtes SQL lentes. C’est souvent là que vous détectez des « vulnérabilités de performance » qui deviennent des failles de disponibilité.

Sessions, authentification et cas PrestaShop : scanner sans casser le back-office

Scanner une boutique anonyme (front) est facile ; scanner un back-office authentifié (PrestaShop 8.1 / 9.1 / 9.2 en 2026, PHP 8.2/8.3 typiquement) est une autre histoire. La difficulté n’est pas « d’avoir un cookie », c’est de maintenir une session stable malgré les protections CSRF, les tokens et parfois du MFA/outils tiers. La méthode la plus robuste reste : (a) se connecter manuellement dans le navigateur sur le staging, (b) récupérer le cookie de session (et éventuellement un header), (c) le passer à Wapiti. Selon vos contraintes, vous pouvez aussi placer un proxy d’interception (ex. Burp/mitmproxy) pour observer les redirects et confirmer que le scanner reste authentifié.

Deux bonnes pratiques très concrètes pour PrestaShop :

utiliser un compte admin dédié au scan (sur staging), avec des droits limités si possible (profil/permissions), pour réduire l’impact d’un mauvais parcours ;
faire expirer/renouveler ce compte et ses secrets régulièrement (sinon le cookie « traîne » dans des historiques de shell et des artefacts).

Exemple de pattern (à adapter à votre version Wapiti via --help) :

# Exemple : scan limité sur un back-office de staging (ne pas lancer en prod)
wapiti \
  -u "https://staging.example.tld/admin-dev/" \
  --cookie "PrestaShop-123456=...; PHPSESSID=..." \
  -m "xss,sql,exec,file" \
  -f json \
  -o wapiti-report.json

Trois précautions spécifiques PrestaShop :

1) Évitez les parcours destructifs : le crawler peut soumettre des formulaires (création de paniers, modifications de compte, envoi d’emails). Sur un staging, isolez les intégrations (SMTP vers une boîte de test, PSP en mode sandbox). Si votre staging est trop proche de la prod, vous allez générer des effets de bord (stocks, commandes, webhooks). Sur le volet webhooks, gardez un contrôle strict comme décrit dans Webhooks PayPal : vérifier l’authenticité des notifications serveur.

2) Routes et tokens d’admin : PrestaShop (surtout 9.x) mélange historiques et composants Symfony. Certaines pages admin comportent des tokens et des paramètres dynamiques ; un scanner peut « sortir » du parcours normal. D’où l’intérêt d’un scope strict, et d’une seed list d’URL (dashboard, modules, logs, recherche commande) plutôt que le crawl intégral. En pratique, beaucoup d’équipes commencent par scanner :

la page de login admin (comportements de redirection, headers, cookies),
les pages de configuration des modules les plus critiques,
les pages qui manipulent des fichiers (import/export, logs, thèmes).

3) Modules à risque : le cœur est rarement la seule surface. Les modules de recherche/facettes, les connecteurs ERP, les exports CSV, les endpoints AJAX et certains helpers legacy sont des zones à scanner en priorité. Si vous avez déjà investigué des CVE ou des analyses d’exploit, vous savez où regarder (ex. pour une classe de vulnérabilités liée à la désérialisation et à unserialize(), voir : Vulnérabilité PrestaShop ps_facetedsearch : analyse RCE via unserialize()). Wapiti ne « prouvera » pas forcément une RCE avancée, mais il peut révéler des symptômes (paramètres anormaux, endpoints exposés, erreurs applicatives) utiles au triage.

Lecture des résultats : preuves, faux positifs, et passage en correctif

Un rapport DAST exploitable doit contenir : URL exacte, méthode, paramètre, payload, extrait de réponse / preuve, et un contexte de reproductibilité (cookie, headers, préconditions). Wapiti produit des rapports en plusieurs formats (HTML/JSON selon versions). En pratique, le JSON est le plus utile pour : (1) archiver dans un artefact CI, (2) filtrer par sévérité, (3) créer des tickets. Le HTML est utile pour un partage ponctuel, mais il est rarement « diffable ».

Le point faible de la boîte noire, ce sont les faux positifs (et parfois les faux négatifs). Typiquement :

Une injection SQL « détectée » parce que l’application renvoie une page d’erreur générique, ou qu’un WAF transforme la réponse.
Une XSS « potentielle » signalée sur un paramètre reflété, mais encodé correctement en contexte (HTML/attribut/JS), ou neutralisé par une CSP.
Des endpoints « intéressants » (backup files, anciennes routes) qui existent en staging mais pas en prod (ou l’inverse).

Pour que le triage soit rapide, adoptez une routine de confirmation adaptée au type de finding. Exemple de grille simple (utile en équipe, et facile à transformer en checklist) :

Finding DAST	Confirmation rapide (10–20 min)	Résultat attendu pour « valider »
XSS réfléchie	reproduire avec un payload inoffensif + vérifier le contexte (HTML, attribut, JS) + vérifier encodage	exécution JS prouvée dans le bon contexte, ou reflet non encodé exploitable
SQLi suspectée	reproduire sur une même route avec variations + observer erreurs/temps + corréler logs SQL côté serveur	preuve stable (erreur SQL spécifique, time-based consistant) et impact démontrable
LFI/RFI	tester sur un endpoint de fichier (download, image, template) + vérifier normalisation des chemins	lecture d’un fichier non prévu (même partielle) ou contournement de restriction
Command execution	très rare en « pur » DAST	preuve indirecte (comportement, erreur) + validation manuelle ciblée

Le triage doit être outillé. Exemple minimaliste : extraire les findings, dédoublonner par route+paramètre, et prioriser ceux qui touchent (a) authentifié admin, (b) endpoints de paiement, (c) upload/import. Sur un Linux de CI, un jq bien ciblé vous fait gagner du temps, même si le schéma exact dépend du JSON généré par votre version Wapiti :

jq '.vulnerabilities[] | {type, level, url, parameter, method}' wapiti-report.json \
  | sed 's/\\n/ /g' \
  | sort -u

Côté correction, il faut relier la preuve à une cause. Pour les injections SQL : requêtes paramétrées (Doctrine DBAL / PDO), suppression des concaténations, validation stricte des types, et surtout revue des repositories/modules legacy. Pour les XSS : encodage contextuel, twig auto-escape côté Symfony, et vérification des smarty modifiers côté front PrestaShop.

Un enchaînement « sain » (et mesurable) après détection :

confirmer et reproduire avec une preuve minimale ;
corriger dans le module / override / template concerné ;
retester la route (idéalement avec un test automatisé, même simple) ;
relancer un scan ciblé Wapiti sur les URLs affectées ;
documenter la mitigation (ex. encodage, validation, headers).

Pour les erreurs de configuration : headers, TLS, durcissement serveur (voir : Symfony : sécuriser un serveur PHP avec hardening et gestion CVE et HTTPS SEO : bonnes pratiques, certificats SSL et audit technique).

Industrialiser : Wapiti dans un pipeline CI/CD sans se mentir sur les garanties

L’intégration CI/CD est utile si vous acceptez une contrainte : un DAST est lent et parfois flaky (dépend du réseau, de l’état de l’appli, de la donnée). La bonne pratique est de le rendre prévisible : (1) exécuter sur staging reconstruit à l’identique, (2) limiter le scope, (3) fixer une durée max, (4) versionner la commande. Pour une démarche « démos à la demande » ou environnements éphémères, l’approche décrite dans PrestaShop CI/CD : générer des démos à la demande en minutes se marie bien avec un scan Wapiti déclenché en post-déploiement.

Un pattern opérationnel :

Job 1 : build + déploiement staging éphémère.
Job 2 : smoke tests (HTTP 200/302 attendus, login admin OK).
Job 3 : scan Wapiti ciblé (front + quelques routes admin), export JSON.
Job 4 : parsing des résultats, politique « fail » uniquement au-dessus d’un seuil (ex. vulnérabilités de niveau élevé, ou nouvelles vulnérabilités vs baseline).

Si vous avez besoin d’un exemple minimal de « job de scan » (à adapter à votre CI), l’idée est surtout de produire un artefact et de plafonner la durée. Exemple générique (pseudo-pipeline, à traduire selon GitLab/GitHub Actions/Jenkins) :

# 1) installer l'outil (ou utiliser une image préconstruite)
pipx install wapiti3

# 2) exécuter un scan borné et produire un rapport
timeout 25m wapiti -u "$TARGET_URL" -m "xss,sql" -f json -o wapiti-report.json

# 3) archiver l'artefact + parser (jq) pour un résumé lisible
jq '.vulnerabilities | length' wapiti-report.json

Ne faites pas échouer le pipeline à la première alerte sans contexte, sinon l’équipe va désactiver le job. La bonne approche est un baseline (rapport de référence) puis un diff sur les nouveaux findings. Ça impose un stockage d’artefacts et un minimum d’ingénierie autour du reporting. Si votre chaîne CI doit aussi couvrir la supply chain (composer, npm), vous retombez sur une stratégie globale (SBOM + scan deps + DAST + revue).

Enfin, attention aux couches intermédiaires : CDN, WAF, cache applicatif. Un scan peut être faussé par des réponses mises en cache ou par des challenges anti-bots. C’est aussi une opportunité : si votre boutique est derrière un CDN/WAF, vous devez savoir ce que ces couches bloquent réellement.

Deux astuces utiles pour fiabiliser l’observation :

sur staging, exécuter un scan en contournant le cache (si possible) ou en variant des en-têtes afin d’éviter une réponse « cache-hit » identique ;
exécuter un scan avec et sans WAF (staging) pour distinguer une correction applicative d’un simple filtrage.

Pour cadrer la partie CDN (latence, cache, règles), voir : CDN : comparatif Cloudflare, Fastly, Akamai, CloudFront, Bunny.net, KeyCDN et PrestaShop : optimiser performance via cache Smarty, CCC et CDN. Un scan de sécurité doit idéalement pouvoir être exécuté avec et sans ces couches (sur staging) pour distinguer une correction applicative d’un contournement « WAF-only ».

Limites assumées et compléments indispensables (sinon vous ratez l’essentiel)

Wapiti est utile, mais il a des limites structurelles : pas de vision du code, difficulté sur les workflows multi-étapes, couverture faible des failles logiques (discount abuse, IDOR complexes, fraude, contournement d’état), et résultats sensibles aux protections anti-automatisation. Le projet Wapiti le formule ainsi : « Wapiti allows you to audit the security of your websites or web applications » (documentation du projet, https://github.com/wapiti-scanner/wapiti). « Audit » ici ne veut pas dire « garantie » : ça veut dire « tests automatisés sur une surface observable ».

Si vous cherchez un standard de référence pour structurer vos tests au-delà d’un scanner, le OWASP Web Security Testing Guide (WSTG) est la base : https://owasp.org/www-project-web-security-testing-guide/. C’est typiquement ce que vous utilisez pour compléter Wapiti avec des tests manuels (contrôles d’accès, session management, logique métier), et pour cadrer le niveau de preuve attendu avant d’ouvrir un ticket “security”.

Pour cadrer une campagne de tests de sécurité de façon plus « méthodo » (périmètre, règles d’engagement, types de tests), un autre document utile est le guide NIST dédié aux évaluations de sécurité : https://csrc.nist.gov/publications/detail/sp/800-115/final. Ce n’est pas spécifique à PrestaShop, mais ça aide à formaliser ce que votre DAST couvre (et ne couvre pas), surtout si vous travaillez avec plusieurs parties prenantes (agence, DSI, hébergeur).

Sur PrestaShop, le « vrai » risque en production est rarement une XSS isolée ; c’est plutôt la combinaison : module vulnérable + admin compromis + exfiltration + skimmer. Si vous voulez un exemple concret de chaîne d’attaque côté e-commerce, vous pouvez lire : Skimmer Magecart PrestaShop : détecter et nettoyer une infection. Dans cette logique, Wapiti est une brique « prévention/détection amont » : il réduit la surface d’attaque en identifiant des points faibles exposés, mais c’est votre pipeline (patch management, durcissement serveur, contrôle des accès, journalisation, supervision) qui transforme un finding en réduction mesurable du risque.

En résumé opérationnel : utilisez Wapiti pour détecter tôt et répéter souvent, mais ne l’utilisez pas pour « prouver la sécurité ». Une posture mature, surtout en contexte e-commerce, combine : staging fidèle, scans bornés, triage discipliné, correctifs traçables, et contrôles complémentaires (SCA/SBOM, hardening, tests manuels ciblés selon WSTG).