DAST : ce que cinq scanners prouvent vraiment sur une
même application

Le rapport de ZAP tombe : 78 signalements. Une soixantaine relèvent de l'hygiène (en-têtes, versions, cookies), une poignée parle d'injection. Personne ne sait, à ce stade, lesquelles de ces lignes correspondent à une attaque qui a vraiment marché, ni surtout ce que le scanner a laissé passer sans rien écrire. C'est la question qu'on a posée à sept configurations de scanners, sur une application dont on connaissait d'avance toutes les failles.

Le DAST, pour dynamic application security testing, teste une application pendant qu'elle tourne, de l'extérieur, sans jamais lire son code. Un scanner part d'une URL, découvre les pages et les paramètres, envoie des requêtes forgées (un guillemet dans un champ de recherche, un <script> dans un formulaire, un chemin tordu vers un fichier système) et note ce qui réagit de travers. Sur notre banc, c'est l'application elle-même qui tenait les comptes. Résultat : le meilleur outil fait prouver 12 failles sur 27, et les sept configurations réunies n'en prouvent que 14.

Sept configurations, 600 secondes : 12 failles prouvées au mieux

La cible est une petite application PHP rendue côté serveur, volontairement vulnérable, avec 27 failles plantées : 18 accessibles sans compte, 6 derrière un compte client, 3 réservées à l'administrateur. Chaque outil a eu 600 secondes et une session client ouverte par le harnais. Aucun n'avait le compte administrateur. Le crédit ne vient pas du rapport : chaque faille porte un capteur dans le code de l'application, qui enregistre l'effet réel de l'exploitation (la requête SQL détournée, le fichier lu, la commande exécutée). Une charge simplement renvoyée dans la page ne suffit pas.

Le premier enseignement est que le volume ne prédit rien. nuclei, avec ses templates par défaut, envoie 9 292 requêtes et fait prouver une seule faille, une XSS réfléchie. Notre moteur en envoie 10 519 pour 6, Wapiti 8 936 pour 8, et ZAP en mode passif 1 452 pour 3. Les trois de ZAP passif ne demandent d'ailleurs aucune charge d'attaque : certaines failles plantées se prouvent sans attaque, en se connectant ou en affichant une page (un cookie de session émis sans ses drapeaux, un script tiers chargé sans contrôle d'intégrité), ou en remplissant un formulaire de mot de passe oublié avec une adresse inconnue. Un scanner passif les ramasse en se contentant de naviguer.

Le deuxième enseignement tient à ce qu'on compte. Si l'on ne garde que les 19 failles dont la preuve est l'exploitation elle-même, les injections au sens large (SQL, inclusion de fichier, XSS, commande, en-tête de mail par exemple), l'écart se creuse : 8 pour ZAP actif, 4 pour Wapiti, 3 pour notre moteur, 1 pour nuclei, 0 pour ZAP passif et Nikto. Notre moteur ne prouve aucune faille qu'un autre outil n'ait aussi prouvée, et ses trois injections tombent à 581, 593 et 595 secondes, sur une fenêtre qui fermait à 601,5. Une autre exécution du même moteur n'en prouve qu'une, à 583 secondes : d'où la fourchette de 4 à 6 failles selon l'exécution, qui ne doit rien au nombre de comptes et tout à la coupure.

Atteindre, attaquer, prouver : où chaque scanner décroche

Le banc enregistre trois signaux par faille, et ils séparent trois échecs différents. La route a-t-elle été requêtée (atteinte) ? Le paramètre vulnérable a-t-il reçu autre chose que sa valeur normale (attaque) ? L'exploitation a-t-elle produit son effet (preuve) ? Un outil qui n'atteint pas la route a un problème de découverte. Un outil qui l'atteint sans prouver a un problème de charge utile ou de temps.

La lecture est instructive. ZAP en mode passif atteint 24 routes sur 27, autant que Wapiti, mais n'en prouve que 3 : la découverte est bonne, il n'attaque pas, c'est son mode. Wapiti attaque 18 paramètres, plus que tout le monde, et n'en convertit que 8. ZAP actif est le plus efficace du lot : 13 paramètres attaqués, 12 failles prouvées. Notre moteur perd du terrain dès la découverte, avec 18 routes atteintes. Nikto et nuclei par défaut ne cherchent pas la même chose : ils inventorient des fichiers connus, des versions et des mauvaises configurations, et touchent 4 et 5 des routes vulnérables.

Le DAST : tester sans le code source

Une analyse statique lit vos fichiers à froid ; le dynamic application security testing ne lit rien du tout. Il crawle l'application pour découvrir ses pages, ses formulaires et ses paramètres, puis envoie des requêtes malveillantes et observe les réponses. Un code d'erreur SQL qui remonte dans la page, un payload réfléchi tel quel dans le HTML, une redirection qui obéit à un paramètre contrôlé : chaque réaction anormale devient un indice de faille.

C'est une posture de boîte noire. Le scanner ne sait pas si votre back-end est en Go, en PHP ou en Node : il ne raisonne que sur ce qui sort par le port 443. Là où l'analyse statique dit "cette fonction pourrait être vulnérable", le DAST dit "j'ai envoyé cette requête et l'application a mal réagi". Le banc montre aussi la limite de cette promesse : "mal réagi" ne veut pas dire "exploité", et c'est pour cela qu'on a fait noter l'application plutôt que le scanner.

Un bon scanner ne se contente pas de repérer un motif suspect, il rejoue l'attaque pour confirmer. Les classiques du marché, du ZAP open-source aux solutions DAST commerciales, reposent tous sur cette boucle : découvrir, injecter, observer, confirmer.

Ce que le DAST a prouvé, et ce qu'aucun outil n'a touché

Les 14 failles prouvées par au moins une configuration dessinent assez bien le terrain du test dynamique :

• Les injections classiques. Deux injections SQL aveugles sur trois, une inclusion de fichier sur deux accessibles sans compte, la traversée de chemin du téléchargement public, l'injection d'en-tête dans le formulaire de contact, l'injection de commande du dépôt de documents. Le scanner envoie une charge, l'application la traite, la réponse trahit le problème.
• Les XSS réfléchies. Les trois XSS réfléchies plantées ont été prouvées, toutes par ZAP actif, deux aussi par Wapiti ou nuclei. C'est le terrain idéal du DAST, parce qu'il voit sa charge ressortir.
• Ce qui se voit sans attaque, ou presque. Les drapeaux de cookie manquants et le script tiers sans contrôle d'intégrité ont été prouvés par quatre configurations chacun, y compris en mode passif. L'énumération de comptes sur les pages de connexion et de mot de passe oublié, par deux et trois. Et le mot de passe que le cookie "rester connecté" transporte en clair, par Wapiti seul.

Et le reste : 13 failles qu'aucune des sept configurations n'a prouvées. Trois sont dans la console d'administration, hors d'atteinte par construction. Les dix autres sont plus parlantes : l'injection SQL et la traversée de chemin de l'espace client, le dépôt de fichier sans contrôle, deux désérialisations PHP, deux injections CSV, une inclusion de fichier sur la page d'accueil, le hachage faible des mots de passe et la fixation de session. Sur les 9 failles qui demandent d'être connecté, une seule a été prouvée, par Wapiti (une injection de commande dans le dépôt de documents du compte client), alors que tous les outils avaient une session valide.

Prouver n'est pas rapporter

Une faille déclenchée n'est utile que si elle arrive dans le rapport. Wapiti, arrêté par le budget, n'a pas écrit le sien : 8 failles prouvées, zéro signalée. Le pilote de banc lui avait fixé des plafonds internes (510 s de scan, 150 s d'attaque) qu'il a dépassés, donc cette absence tient en partie au réglage. Le rapport de notre moteur n'a pas pu être récupéré : le client du pilote de banc refusait un message de 4,24 Mo, au-delà de sa limite par défaut de 4 Mo. Le défaut est dans l'outillage du banc, pas dans l'outil, mais le résultat pour un lecteur est le même. ZAP actif, seul des trois scanners actifs à finir dans le temps, présente 9 de ses 12 preuves dans son rapport, et ZAP passif 2 sur 3. Ce dernier indicateur a été ajouté après lecture des résultats, pas défini avant : lisez-le comme une description.

Ses angles morts, qu'il faut connaître avant de s'y fier

Le DAST a une faiblesse structurelle : il ne voit que ce qu'il atteint, et il n'atteint que ce qu'il découvre. Le banc ajoute une nuance : même ce qu'il atteint, il ne le prouve pas forcément.

• La couverture dépend du crawl. Notre cible est une application PHP rendue côté serveur, le cas le plus facile pour un crawler. Une single-page application qui construit ses routes en JavaScript ou une API sans documentation sont plus dures, et notre banc ne les a pas mesurées. Donner au scanner la vraie surface (une spécification OpenAPI, une liste d'URL à paramètres, une session enregistrée) reste la moitié du travail.
• L'authentification et l'état le piègent. Avec une session valide, une seule faille sur les neuf authentifiées a été prouvée. Tester des parcours qui exigent un état précis (dépôt de fichier, devis, historique de commandes) demande une configuration que les réglages par défaut n'apportent pas.
• Aucune vue du code. Le DAST dit "ce paramètre est injectable", jamais "à cause de la ligne 214 qui concatène la requête". Pour le développeur qui corrige, c'est un point de départ, pas une localisation.
• Les failles logiques lui échappent. Un contrôle d'accès cassé où l'utilisateur A lit les données de l'utilisateur B, une remise appliquée deux fois, un workflow court-circuité : ces bugs ne ressemblent à aucun motif d'attaque générique. Notre cible n'en contenait pas, donc le banc ne mesure pas ce point.

DAST, SAST et IAST : le même problème vu sous trois angles

Le SAST lit le code à l'arrêt et voit tout, y compris les chemins jamais exécutés, au prix d'un déluge d'alertes. Le DAST attaque l'appli en marche et ne voit que le réellement exposé. L'IAST joue les intermédiaires en instrumentant le runtime depuis l'intérieur, un peu comme notre banc instrumente sa cible pour noter les scanners. Aucun n'est meilleur dans l'absolu : ils ne regardent pas l'application au même moment ni depuis le même endroit.

Le comparatif complet, faux positifs compris, et ce que l'IA vient y changer, est dans l'article pilier SAST, DAST, IAST : comparatif et ce que l'IA change. Si vous hésitez sur lequel déployer en premier, c'est la lecture à faire avant d'acheter quoi que ce soit.

Où le DAST s'insère dans la CI/CD

Contrairement au SAST, le DAST ne peut pas tourner sur chaque commit : il lui faut une application déployée et fonctionnelle. On ne le colle donc pas sur la pull request, on le déclenche après le déploiement en staging, et on ne bloque la promotion vers la production que sur les findings sérieux :

# Le DAST tourne après déploiement en staging, pas sur la PR
dast:
  stage: deploy
  script:
    - deploy-to-staging
    - run-dast --target https://staging.example.com --report dast.sarif
    - check-findings dast.sarif --fail-on high,critical
  rules:
    - if: '$CI_COMMIT_BRANCH == "staging"'   # jamais sur chaque commit

Le banc donne deux consignes de réglage. D'abord, le budget compte : à 600 secondes, Wapiti et notre moteur ont été coupés, et la sixième preuve de notre moteur est arrivée 6 secondes avant la fermeture. Un passage ciblé à chaque déploiement et un scan long planifié la nuit tiennent mieux qu'un scan unique trop court. Ensuite, vérifiez que le rapport sort bel et bien : un scanner arrêté au budget peut avoir déclenché des failles sans en écrire une ligne. Le câblage complet (placement, format SARIF, security gate qui bloque sans noyer les développeurs) est détaillé dans intégrer SAST et DAST dans sa CI/CD.

La mesure : méthode, cadre et limites

Mesure faite le 7 octobre 2026 sur ptaas-bench (commit 85f8f61), en local, sur des conteneurs volontairement vulnérables : aucune cible tierce n'a été touchée. Outils et versions : ZAP stable en mode passif (spider et spider Ajax) puis actif (avec le scanner actif), Wapiti 3.3.2, nuclei 3.11.1 avec ses templates par défaut puis en mode -dast, Nikto 2.6.1 et notre moteur en mode pentest complet. La cible est réinitialisée et vérifiée entre chaque passage, et une seule analyse tourne à la fois. Une contre-expertise adverse a recompté le 8 octobre toutes les preuves et les requêtes à partir des événements bruts de la cible : les chiffres sont identiques.

Les limites, maintenant, et elles sont réelles :

• Une seule cible. Une application PHP rendue côté serveur, 27 failles sur les 169 du banc. Les deux applications à page unique et la cible d'infrastructure prévues n'ont pas été mesurées : rien ici ne vaut pour une SPA ou une API.
• Une exécution par outil. La stabilité n'est vérifiée que pour Wapiti (deux exécutions, les mêmes 8 failles) et ZAP passif (trois exécutions, 3 failles à chaque fois). Notre moteur varie de 4 à 6.
• Des budgets qui ne sont pas strictement égaux. Tous avaient 600 s, mais avec une grâce de 90 s pour les scanners tiers contre 30 s pour notre moteur : la fenêtre réelle de Wapiti a duré 694 s, celle de notre moteur 601,5 s. Toutes les preuves de Wapiti arrivent avant 91 s, donc la grâce ne change rien pour lui. ZAP actif s'est arrêté seul à 391 s, sous les plafonds fixés par le pilote : il n'a pas utilisé tout le budget.
• Une machine pas toujours calme. Une première passe a tourné sur un hôte saturé et a été rejouée. Pendant les deux passages ZAP retenus, la charge moyenne restait de 6,0 et 7,5 sur 8 cœurs, l'outil compris.
• Un compte client, jamais l'administrateur. Les 3 failles de la console admin sont hors d'atteinte pour tous. Le collecteur du banc rejette par ailleurs les lots d'événements qui contiennent un octet nul, ce qui peut sous-créditer un outil qui envoie des charges en %00.
• Aucun modèle de langage. Aucun outil de ce banc, le nôtre compris, n'appelle de modèle de langage sur ce chemin. C'est une mesure de scanners déterministes, pas de "pentest IA".

À retenir

• Le DAST (dynamic application security testing) teste une application en cours d'exécution, en boîte noire, sans accès au code : il envoie des requêtes et déduit les failles des réponses.
• Sur notre banc (une application PHP, 27 failles, 600 s, un compte client), ZAP actif fait prouver 12 failles, Wapiti 8, notre moteur 4 à 6, ZAP passif 3, nuclei par défaut 1, Nikto 0. Le banc est le nôtre et notre moteur a été réglé contre lui.
• Les sept configurations réunies prouvent 14 failles sur 27, et une seule des 9 qui demandent d'être connecté.
• Le volume de requêtes ne prédit rien, et un scanner qui ne lance pas d'attaque ne prouve que ce qui se voit en naviguant. nuclei -dast sans liste d'URL ne teste presque rien.
• Prouver n'est pas rapporter : vérifiez que votre scanner finit dans son budget et écrit son rapport.
• Dans la CI/CD, il tourne après déploiement en staging, et il complète le SAST et le pentest humain au lieu de les remplacer.

Ce banc dit surtout une chose : le meilleur scanner laisse plus de la moitié des failles plantées sans preuve, et presque tout ce qui se trouve derrière un login. C'est l'espace d'un pentest web en boîte noire, où un humain configure ses sessions, teste les droits et enchaîne les failles. Le détail outil par outil, faille par faille, est dans notre article sur le pentest automatisé mesuré sur deux bancs, et la place du DAST parmi les autres familles d'outils dans quel scanner de vulnérabilité pour quel besoin. Pour parler de votre contexte à un humain, la page contact est là pour ça.

Questions fréquentes