DAST (Dynamic Application Security Testing)
Le DAST teste une application en cours d'exécution, de l'extérieur, en lui envoyant des requêtes malveillantes pour détecter injections, XSS et défauts de configuration.
Le Dynamic Application Security Testing, ou DAST, teste une application pendant qu'elle tourne, de l'extérieur et sans accès au code source. L'outil explore l'application comme le ferait un utilisateur, cartographie ses pages et ses API, puis injecte des payloads dans chaque paramètre pour provoquer des comportements révélateurs : injection SQL, XSS, traversée de répertoires, défauts de configuration. C'est l'approche "boîte noire" de l'analyse de sécurité applicative.
Sa grande force tient en un mot : la preuve. Quand un DAST remonte une injection, c'est qu'il l'a déclenchée sur l'application réelle, avec sa configuration réelle ; le taux de faux positifs est donc structurellement plus bas qu'en analyse statique. En contrepartie, sa couverture dépend de ce qu'il parvient à explorer, et les parcours derrière authentification ou la logique métier lui échappent en partie.
Le DAST se combine naturellement avec le SAST, qui lit le code, et les deux trouvent leur place dans la chaîne de livraison, comme nous le montrons dans nos articles SAST, DAST, IAST à l'ère de l'IA et intégrer SAST et DAST dans la CI/CD.
Les trois angles morts du DAST
Ils reviennent dans toutes les campagnes. L'authentification d'abord : si le robot ne sait pas se connecter et maintenir sa session, il teste la page de login et rien d'autre. Les applications à rendu JavaScript ensuite, où l'exploration classique ne voit qu'une page vide tant qu'aucun navigateur n'exécute le code. La logique métier enfin : un DAST ne saura jamais qu'un utilisateur ne devrait pas pouvoir valider sa propre commande, parce que rien dans la réponse HTTP ne le lui dit. On compense en fournissant à l'outil des identifiants de test, une spécification OpenAPI pour les API exposées, et un testeur humain pour le reste.
Où le brancher dans la chaîne de livraison
Le réflexe est de mettre le DAST dans la CI et de bloquer la fusion au moindre finding. C'est le meilleur moyen de le voir désactivé en trois semaines. Un scan complet prend des dizaines de minutes, parfois des heures : sa place est sur l'environnement de recette, la nuit ou à chaque livraison, pas sur chaque commit. La CI, elle, garde les contrôles rapides, SAST ciblé sur le code modifié et SCA sur les dépendances. Notre article sur l'intégration de SAST et DAST dans la CI/CD donne le découpage complet, étape par étape.
Questions fréquentes
DAST et pentest, est-ce la même chose ?
Non. Le DAST est un outil automatique qui rejoue un catalogue de payloads connus. Un pentest est une mission humaine qui enchaîne des vulnérabilités, contourne des protections et éprouve la logique métier. Le DAST couvre le volume, le pentest couvre la profondeur.
Peut-on lancer un DAST sur la production ?
Techniquement oui, avec des précautions : compte de test dédié, débit limité, exclusion des formulaires qui déclenchent des envois d'e-mails ou des paiements. Un environnement de recette identique à la production reste préférable quand il existe.
Le DAST détecte-t-il les vulnérabilités des dépendances ?
Indirectement seulement, quand la version vulnérable se trahit par une bannière ou un comportement observable. Pour l'inventaire des composants, c'est la SCA qui répond, et la SBOM qui documente.