Chaque application web est une surface d''attaque, et la vérité inconfortable est que tu ne peux pas sécuriser ce que tu n''as pas testé contre les véritables attaques. L''analyse statique lit ton code source et signale les motifs suspects, mais elle ne peut pas te dire si l''application déployée fuit réellement des données, accepte une charge utile injectée ou expose un panneau d''administration non authentifié. Cela nécessite de piquer l''application en cours d''exécution de l''extérieur comme le ferait un attaquant — le test de sécurité des applications dynamique, ou DAST. La bonne nouvelle pour 2026 est que l''écosystème DAST open-source est mature, capable et gratuit, couvrant tout des vérifications rapides des CVE connus au scannage d''attaque complet des applications. Le hic c''est qu''aucun outil ne fait tout bien, et utiliser un où tu en as besoin laisse des lacunes.
Ce guide explique comment fonctionne DAST, pourquoi les outils open-source sont complémentaires plutôt que concurrents, et comment les assembler dans un pipeline de scannage en couches qui s''insère dans CI/CD. Les principaux personnages sont ZAP, l''analyseur proxy complet ; Nuclei, l''analyseur de vulnérabilité basé sur modèle rapide ; Wapiti, l''analyseur fuzzing en ligne de commande ; et Nikto, le vérificateur de configuration du serveur vétéran. Comprendre à quoi chacun sert pour c''est comment tu construis une couverture au lieu de redondance.
Ce que DAST fait réellement
Le test dynamique traite l''application comme une boîte noire. Plutôt que de lire le code, un outil DAST interagit avec l''application en cours d''exécution via HTTP — crawlant ses pages, soumettant des formulaires, appelant ses API — et observe comment elle réagit à l''entrée normale et malveillante. Si envoyer '' OR 1=1-- dans un paramètre change la réponse d''une manière qui suggère que la requête s''est exécutée, c''est un signal d''injection SQL. Si une balise de script réfléchie revient non échappée dans la page, c''est un cross-site scripting. DAST attrape les vulnérabilités qui n''existent qu''au runtime : les flaws d''injection, les problèmes d''authentification et de session, les misconfigurations, les endpoints exposés et les problèmes qui émergent de la façon dont les composants interagissent réellement quand ils sont déployés.
La grande force de DAST est qu''il teste la réalité — le système réel en cours d''exécution, y compris son serveur, sa configuration et son comportement à l''exécution, pas un modèle abstrait de la source. Sa faiblesse correspondante est qu''il ne teste que ce qu''il peut atteindre : si le crawler ne trouve jamais une page, ou ne peut pas s''authentifier, ou ne comprend pas le routage côté client d''une application monopage, cette surface reste non testée. C''est pourquoi la qualité du crawling et le support d''authentification importent autant, et pourquoi les outils diffèrent significativement dans la façon dont ils découvrent la véritableSurface d''une application. C''est aussi pourquoi DAST complète plutôt que remplace l''analyse statique et le scannage de dépendance — chacun voit ce que les autres sont aveugles.
ZAP : le cheval de trait complet
ZAP (Zed Attack Proxy), maintenu par Checkmarx après sa longue course en tant que phare OWASP, est l''outil DAST open-source le plus complet, et pour de nombreuses équipes c''est toute la pile par lui-même. Son fondation est un proxy d''interception : tu routes un navigateur (ou un crawler automatisé) à travers ZAP, et il enregistre chaque requête et réponse, construisant une carte de l''application. À partir de ce trafic, il exécute des scans passifs (signalant les problèmes du trafic observé sans attaquer) et, à la demande, des scans actifs (envoyant des charges utiles d''attaque pour confirmer les vulnérabilités). Autour de ce noyau il ajoute un spider et un spider Ajax pour les applications riches en JavaScript, un fuzzer, le support WebSocket et le scannage API pour REST, GraphQL et SOAP.
L''avantage décisif de ZAP pour 2026 est l''automatisation. Ses scripts de scan empaquetés — un scan baseline (passif), un scan complet (actif) et un scan API piloté par une spécification OpenAPI — sont conçus pour s''exécuter sans tête dans un conteneur, ce qui rend ZAP un ajustement naturel pour CI/CD. Pointer le scan baseline vers un déploiement de staging à chaque pull request et tu obtiens DAST continue et peu bruyant avec presque aucune configuration. Son Framework d''Automatisation et son API HTTP complet te laissent scripter les scans arbitrairement complexes, et sa gestion du contexte et de l''authentification te laissent tester comme un utilisateur connecté, ce qui est où vivent généralement les vulnérabilités intéressantes. Quand les gens demandent « un outil DAST open-source », ZAP est la réponse, et le cheatsheet ZAP couvre ses modes de scan et son API.
Le tradeoff c''est que la largeur de ZAP s''accompagne d''un poids : c''est un outil substantiel avec une courbe d''apprentissage, et un scan actif complet d''une grande application prend du temps. C''est un coût raisonnable pour sa couverture, mais c''est pourquoi les outils plus légers et plus rapides ont toujours une place à côté.
Nuclei : détection rapide et basée sur modèle
Nuclei, de ProjectDiscovery, attaque une partie différente du problème : la vitesse et la couverture des vulnérabilités connues. Au lieu de crawler et fuzzer, Nuclei exécute une cible contre une énorme bibliothèque de modèles YAML maintenus par la communauté, chacun décrivant comment détecter un problème spécifique — un CVE connu, un credential par défaut, un fichier de configuration exposé, une misconfiguration. Parce que les modèles sont déclaratifs et le moteur de Nuclei est rapide et parallèle, il peut vérifier des milliers de problèmes connus sur plusieurs hôtes en minutes, de manière déterministe.
Cela rend Nuclei le pass initial idéal et la vérification continue idéale. Il excelle à répondre « cette cible est-elle vulnérable à quelque chose de déjà connu ? » — le répertoire .git exposé, le CVE non corrigé, le panneau admin oublié, le login par défaut. Les 12 000+ modèles communautaires signifient que la connaissance collective de la communauté de sécurité est codée et réutilisable, et les nouveaux modèles apparaissent à mesure que les nouvelles vulnérabilités sont divulguées. Dans un pipeline, Nuclei est assez bon marché pour s''exécuter sur chaque déploiement et même contre la production (avec prudence), attrapant les régressions et les problèmes nouvellement divulgués rapidement. Le cheatsheet Nuclei couvre la sélection des modèles et le scannage.
Ce que Nuclei ne fait pas c''est découvrir les vulnérabilités nouvelles dans ta logique d''application spécifique. Il vérifie par rapport à un catalogue de motifs connus ; il ne crawle pas ton app et ne fuzze pas ses paramètres uniques comme ZAP ou Wapiti le font. Ce n''est pas un flaw — c''est la conception — mais c''est exactement pourquoi Nuclei s''associe avec un analyseur de crawling plutôt que de le remplacer.
Wapiti et Nikto : spécialistes focalisés
Deux outils plus légers arrondissent la pile open-source. Wapiti est un analyseur black-box en ligne de commande qui fonctionne comme un fuzzer : il crawle l''application pour énumérer les URL et formulaires, puis injecte les charges utiles dans chaque paramètre et inspecte les réponses à la recherche de signes de vulnérabilité — injection SQL, XSS, divulgation de fichier, injection de commande, SSRF et plus. C''est plus léger et plus scriptable que ZAP, licencié GPL et pip-installable, ce qui le rend facile à déposer dans un travail CI quand tu veux le fuzzing actif sans le footprint complet de ZAP. Ses releases 2026 ont suivi le rythme des nouvelles classes d''attaque, et le cheatsheet Wapiti couvre son système de modules.
Nikto est le vétéran du groupe et occupe une niche étroite mais utile : les vérifications au niveau du serveur. Il scanne un serveur web pour les fichiers dangereux et les CGIs, les logiciels serveur obsolètes et les misconfigurations courants — des milliers de vérifications contre le serveur lui-même plutôt que la logique métier de l''application. C''est rapide, simple et complémentaire : Nikto te dit que le serveur est mal configuré ou exécute quelque chose de dangereux, tandis que ZAP et Wapiti testent l''application s''exécutant dessus. Pour un pass rapide d''hygiène du serveur, cela vaut toujours le coup de s''exécuter.
Assembler un pipeline en couches
Les outils sont complémentaires parce qu''ils couvrent différents axes — largeur de vulnérabilité connue, profondeur de logique d''application et configuration du serveur — et la posture la plus forte les étage par coût et couverture. Un pipeline pratique 2026 ressemble à ceci. Sur chaque déploiement vers staging, exécute Nuclei pour un balayage rapide et large des CVE connus et des exposures, et un scan ZAP baseline (passif) pour les résultats d''applications peu bruyants — les deux sont assez rapides pour gater une pull request. Sur un calendrier (nuit ou par release), exécute les scans plus lourds : un scan ZAP complet et/ou Wapiti pour fuzzer les paramètres et formulaires de l''application à la recherche des flaws d''injection et de logique nouveaux, plus un passage Nikto pour l''hygiène du serveur. Alimente tout dans le même rapport pour que les résultats soient triés ensemble.
Cette couche respecte la réalité que le scannage actif est lent et la vérification CVE connue est rapide, donc tu exécutes la vérification large bon marché constamment et la vérification profonde coûteuse périodiquement. Elle respecte aussi que chaque outil a les angles morts que les autres couvrent : Nuclei manque les bugs de logique app nouveaux que le fuzzing ZAP/Wapiti attrape ; ZAP/Wapiti manquent les CVE nouvellement divulgués que les modèles frais de Nuclei attrapent ; les deux manquent les misconfigurations du serveur que Nikto signale. En exécuter un et tu as un faux sentiment de sécurité ; exécuter l''ensemble en couches et tu as une couverture véritablement. L''erreur la plus courant que les équipes font c''est d''adopter un analyseur unique et d''assumer qu''il est complet — aucun outil DAST ne l''est, et les open-source sont explicitement conçus pour se compléter.
Authentification et portée : où les scans réussissent ou échouent
Un point qui détermine si tout ceci fonctionne : DAST ne teste que ce qu''il peut atteindre, donc la configuration d''authentification et de portée est où les scans réussissent ou échouent silencieusement. Les vulnérabilités les plus graves vivent généralement derrière une connexion — dans l''application authentifiée, les fonctions admin, les données spécifiques à l''utilisateur. Un analyseur qui teste uniquement les pages publiques non authentifiées teste la part la moins intéressante de la surface d''attaque. Chaque outil DAST sérieux supporte le scannage authentifié (les contextes et la gestion de session de ZAP sont particulièrement capables), mais cela prend la configuration : enseigner à l''analyseur comment se connecter, comment reconnaître une session valide et comment éviter de se déconnecter lui-même. Investir dans cette configuration c''est ce qui sépare un scan qui trouve de vrais problèmes d''un qui produit un rapport propre et trompeur.
La portée importe tout autant dans l''autre direction. Un analyseur actif envoie les vraies charges utiles d''attaque, ce qui peut créer des données, déclencher des actions ou stresser un système. Tu dois confiner les scans aux cibles autorisées — ton propre staging ou les environnements explicitement permis — et être délibéré sur l''exécution des scans actifs contre la production. Scannager les systèmes tu ne possèdes pas ou pour lesquels tu n''as pas la permission de tester est illégal, et la puissance qui rend ces outils précieux pour la défense les rend dangereux quand ils sont mal utilisés. Définir la portée, obtenir l''autorisation et préférer le staging pour les scans agressifs.
Gérer les apps modernes : SPAs et APIs
Un défi que le modèle DAST classique n''a pas anticipé c''est qu''une grande part des applications web 2026 ne sont pas des pages rendues sur le serveur qu''un crawler peut parcourir en suivant les liens. Ce sont des applications monopage (SPAs) où le navigateur exécute JavaScript pour construire l''interface et récupérer les données des API, et les API sans tête sans frontend HTML du tout. Les deux brisent un spider naïf : il n''y a pas de liens <a href> à suivre, et la véritableSurface d''attaque est un ensemble d''endpoints d''API invoqués par le code côté client. Un analyseur qui ne comprend que le crawling HTML traditionnel mappera presque aucune d''une telle application et rapportera un résultat réconfortantement vide, entièrement trompeur.
Les outils se sont adaptés, et utiliser le bon mode importe. Pour les SPAs, le Spider Ajax de ZAP pilote un navigateur réel pour exécuter le JavaScript et observer les requêtes que l''application fait réellement, découvrant les appels d''API qu''un spider simple aurait manqués. Pour les API directement, la meilleure voie c''est d''ignorer le crawling entièrement et d''alimenter l''analyseur une spécification : le scan d''API de ZAP consomme une définition OpenAPI (Swagger), SOAP ou GraphQL et teste chaque endpoint et paramètre documentés systématiquement. Cela est souvent plus complet que le crawling, parce que la spécification énumère la surface complète plutôt que de compter sur la découverte. La règle pratique c''est de donner à l''analyseur une carte quand tu en as une — un fichier OpenAPI, une collection Postman, un schéma GraphQL — plutôt que d''espérer qu''il crawle son chemin vers une couverture complète.
Cela reframe aussi où DAST s''insère dans le développement moderne. Quand l''application est API-first, DAST devient le test de sécurité d''API, et l''intégration du schéma d''API dans le pipeline de scan c''est le pas d''intégration du plus haut effet. Une équipe expédiant une API REST ou GraphQL devrait câbler son OpenAPI/schéma dans le scan d''API ZAP dans CI, pour que chaque endpoint soit testé sur chaque changement. Traiter la spécification comme la cible du scan, plutôt que l''interface utilisateur rendue, c''est comment DAST reste efficace à mesure que les applications s''éloignent du HTML rendu sur le serveur.
Le résumé
Le test de sécurité des applications dynamiques attrape les vulnérabilités qui n''existent que quand ton application s''exécute réellement, et en 2026 la pile DAST open-source couvre la gamme entière gratuitement — si tu l''utilises comme un ensemble en couches plutôt que de parier sur un outil. Exécute Nuclei pour la détection rapide et continue des CVE connus et des exposures ; exécute ZAP comme ton cheval de trait complet crawling-and-active-scanning avec l''automatisation CI de première classe ; ajoute Wapiti pour le fuzzing léger en ligne de commande et Nikto pour l''hygiène de configuration du serveur. Étage les vérifications rapides sur chaque déploiement et les scans profonds sur un calendrier, investis dans le scannage authentifié pour que tu testes la surface qui importe, confine les scans actifs aux cibles autorisées, et tu transformes « nous espérons que l''app est sécurisée » en « nous la testons contre les véritables attaques continuellement ».
Références et Ressources
Outils
Contexte et analyse
- Alternatives Nuclei 2026 : Analyseurs Vuln Plus Rapides — AppSec Santa
- Comparaison des Outils DAST Open-Source — ZAP, Nuclei, Wapiti, Nikto
- Meilleurs Outils DAST Gratuits en 2026
Cheatsheets connexes 1337skills