DAST (Dynamic Application Security Testing) : tester une appli en
cours d'exécution

Le DAST teste une application pendant qu'elle tourne, de l'extérieur, sans jamais lire son code. Le nom complet le dit déjà : dynamic application security testing, un test de sécurité dynamique, mené en aveugle sur les sources. Concrètement, un scanner part d'une URL, découvre les pages et les paramètres que l'application expose, envoie des requêtes forgées (un guillemet glissé dans un champ de recherche, un <script> dans un formulaire, un chemin tordu vers /admin, un en-tête Host falsifié) et il note tout ce qui réagit de travers. Il ne raisonne que sur ce qui sort par le port 443.

Le terme est resté anglais, même en France, et c'est celui qu'on tape dans Google. Autant l'employer tel quel. Reste à voir, sans le vernis marketing, ce que cette approche attrape vraiment et ce qu'elle laisse filer.

Le DAST, ou l'art de tester sans le code source

La bascule mentale est simple. Une analyse statique lit vos fichiers à froid ; le dynamic application security testing ne lit rien du tout. Il part d'une URL, il crawle l'application pour découvrir ses pages, ses formulaires et ses paramètres, puis il 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 s'en moque : il ne raisonne que sur ce qui sort par le port 443. C'est précisément ce qui le rend crédible. 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 ». La différence entre une hypothèse et une observation.

Notez la dernière étape : un bon scanner ne se contente pas de repérer un motif suspect, il rejoue l'attaque pour confirmer. C'est ce rejeu qui distingue un outil sérieux d'un générateur d'alertes. Les classiques du marché, du OWASP ZAP open-source aux DAST solution commerciales, reposent tous sur cette boucle : découvrir, injecter, observer, confirmer.

Ce que le DAST trouve vraiment bien

Le dynamic testing brille sur tout ce qui ne se voit qu'en conditions réelles, quand l'application, son serveur web, sa configuration et son runtime sont assemblés et vivants. Ses terrains de chasse :

• Les injections classiques. Injection SQL, injection de commande, traversée de répertoire : le scanner envoie une charge, l'application la traite, et la réponse trahit le problème (un message d'erreur du SGBD, une liste de fichiers système, un délai de réponse suspect sur une injection en aveugle).
• Le Cross-Site Scripting réfléchi. Un payload envoyé dans un paramètre qui revient intact dans le HTML de la réponse : c'est typiquement le genre de XSS que le DAST détecte de façon fiable, parce qu'il voit son injection ressortir à l'écran.
• Les erreurs de configuration. En-têtes de sécurité absents, cookies sans HttpOnly, méthodes HTTP dangereuses laissées ouvertes, messages d'erreur trop bavards, TLS mal réglé. Tout ça se lit sur le fil, sans jamais toucher au code.
• Les expositions accidentelles. Un fichier .git accessible, une page d'admin non protégée, une sauvegarde oubliée, une API de debug restée active en préproduction. Le crawl les débusque parce qu'elles répondent, point.

Le point commun de tout ça ? Ce sont des failles qui n'existent pleinement qu'à l'exécution. Une revue de code peut deviner qu'un en-tête manque ; seul un test dynamique confirme que la vraie réponse du vrai serveur, derrière son vrai reverse-proxy, ne le pose pas. Beaucoup de ces catégories sont d'ailleurs au sommet de l'OWASP Top 10, et c'est là que le DAST rend le meilleur service : sur des classes de failles bien cadrées, observables de l'extérieur.

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. Tout ce que son crawler ne trouve pas n'est tout simplement jamais testé. Voilà pourquoi la couverture réelle d'un scan dépend directement de la qualité de la découverte.

• La couverture dépend du crawl. Une single-page application qui construit ses routes en JavaScript, un endpoint d'API non documenté, un workflow accessible seulement après trois formulaires enchaînés : si le crawler ne les voit pas, ils restent hors du champ de tir. La moitié du travail d'un bon scan, c'est de lui donner à manger la vraie surface (une spécification OpenAPI, un enregistrement de session authentifiée).
• Aucune vue du code. Le DAST ignore pourquoi une faille existe. Il dit « ce paramètre est injectable », jamais « à cause de la ligne 214 qui concatène la requête ». Pour le développeur qui doit corriger, c'est un point de départ, pas une localisation.
• L'authentification et l'état le piègent. Un scanner mal configuré se fait déconnecter au bout de trois requêtes, ou pire, déclenche un mot de passe oublié en boucle. Tester des parcours qui exigent un état précis (panier, tunnel de paiement, back-office multi-rôles) demande une configuration soignée que trop d'équipes négligent.
• 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 qu'on peut appliquer deux fois, un workflow qu'on court-circuite : ces bugs métier ne ressemblent à aucun motif d'attaque générique. Le scanner passe à côté parce qu'il ne connaît pas les règles de votre business.

Et oui, malgré son avantage sur le statique, le DAST produit aussi des faux positifs. Une page qui renvoie toujours 200 OK même sur une URL bidon peut lui faire croire à des vulnérabilités partout ; une injection en aveugle basée sur le temps se déclenche à tort si le réseau ralentit. Un rapport DAST se relit, il ne se signe pas les yeux fermés.

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

Prenons le SAST et le DAST côte à côte. L'un 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. L'autre attaque l'appli en marche et ne voit que le réellement exposé, au prix des angles morts qu'on vient de lister. L'IAST, lui, joue les intermédiaires en instrumentant le runtime depuis l'intérieur. Aucun n'est meilleur dans l'absolu : ils ne regardent pas l'application au même moment ni depuis le même endroit.

   SAST                 DAST                  IAST
   ----                 ----                  ----
  lit le code         attaque l'appli       agent DANS l'appli
  à l'arret           en marche             pendant les tests
  (boite blanche)     (boite noire)         (boite grise)
     |                    |                     |
     v                    v                     v
  voit TOUT           voit le              voit le code
  le code             REELLEMENT           ATTEINT en
  (meme mort)         expose               conditions reelles
     |                    |                     |
  bruit eleve         moins de bruit        faux positifs
  faux positifs       faux negatifs         les plus bas
                      sur le code non
                      atteint

On a détaillé ce comparatif, faux positifs compris, et ce que l'IA vient y changer, 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 pour l'attaquer. On ne le colle donc pas sur la pull request, on le déclenche après le déploiement en staging. La logique du shift-left a ses limites : on décale à gauche ce qui peut l'être (le statique, les secrets, l'analyse des dépendances), et on laisse le dynamique à droite, là où une vraie instance répond.

Concrètement, on cible l'environnement de recette 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

Un scan complet peut prendre de longues minutes, parfois des heures sur une grosse surface. L'approche qui tient dans la durée : un passage ciblé à chaque déploiement en staging, et un scan exhaustif planifié la nuit ou le week-end, quand personne n'attend le pipeline. Tout le câblage (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.

Le DAST face à un vrai pentest, et l'apport de l'IA

Un scanner reste un scanner. Il excelle sur les classes de failles connues et répétables, il tourne vite et souvent, il ne se fatigue jamais. Mais il ne raisonne pas. Il ne va pas enchaîner une fuite d'information anodine, un contrôle d'accès un peu lâche et un upload mal filtré pour construire une chaîne d'exploitation complète. Cette créativité, ce sens du « et si je combinais ça avec ça », reste le domaine du testeur humain. C'est aussi la différence de fond qu'on creuse dans le débat entre automatisation et test réel.

C'est là que l'IA rebat les cartes, non pas en remplaçant le pentester, mais en musclant le scanner. Un DAST piloté par IA cesse d'être un crawler bête : il auto-découvre mieux la surface (y compris les API et les workflows multi-étapes qui piégeaient les vieux moteurs), il adapte ses payloads à la techno détectée au lieu de les envoyer en rafale, et il valide par rejeu avant de crier à la faille. Il commence même à tenter des enchaînements simples que le pattern-matching ne voyait pas. On reste loin de l'intuition humaine, mais on grignote sérieusement le terrain qui séparait le scan du pentest.

À 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.
• Il brille sur les failles d'exécution : injections, XSS réfléchi, erreurs de configuration, expositions accidentelles. Ses findings sont moins bruyants que ceux du statique, car il déclenche vraiment le comportement.
• Ses limites : aucune vue du code, couverture dépendante du crawl, angles morts sur les workflows authentifiés et les failles logiques, et des faux positifs à relire malgré tout.
• Il complète le SAST et l'IAST au lieu de les remplacer : chacun regarde l'appli à un moment et depuis un endroit différents.
• Dans la CI/CD, il tourne après déploiement en staging, jamais sur chaque commit ; l'IA en améliore la découverte et la validation, mais ne remplace pas un pentest humain sur les chaînes d'exploitation.

Ce genre de test dynamique, moins bruyant et validé par rejeu, c'est ce qu'on construit côté AppSec augmentée par l'IA. Le produit est en pré-lancement, donc pas de promesse en l'air ici. Si vous préférez d'abord parler de votre contexte à un humain, la page contact est là pour ça.