DAST : 7 cas d'utilisation, exemples, avantages et inconvénients
La capacité des outils DAST à simuler des cyberattaques réelles et à révéler les vulnérabilités en temps réel en fait un atout précieux dans la panoplie d'outils de cybersécurité. Comme le montre le graphique, la popularité des outils DAST a considérablement augmenté ces cinq dernières années.
Étant donné qu'une part importante des attaques logicielles exploite la couche application, il convient de noter que 1 accent mis par DAST sur les tests externes devient encore plus crucial.
Découvrez ci-dessous comment DAST s'intègre aux pipelines DevSecOps, satisfait aux exigences de conformité et détecte les vulnérabilités d'exécution que les outils statiques ne repèrent pas.
Avantages et inconvénients de DAST
Comment fonctionne DAST ?
DAST suit une séquence répétable à chaque exécution sur une application cible.
- Identification de la cible : le scanner est configuré pour cibler une URL ou un ensemble de points de terminaison d’API. Dans les environnements CI/CD, cette configuration est généralement effectuée une seule fois, puis le scanner est déclenché automatiquement à chaque compilation.
- Exploration : Cet outil cartographie la surface d’attaque de l’application en suivant les liens, en soumettant des formulaires et en analysant le JavaScript, dressant ainsi un inventaire de toutes les entrées et tous les points d’accès. Les scanners modernes utilisent un spider AJAX en complément du crawler standard pour traiter les applications monopages à contenu dynamique.
- Simulation d'attaque : pour chaque entrée détectée, le scanner déclenche des attaques : chaînes d'injection SQL, vecteurs XSS, séquences de traversée de répertoire, en-têtes malformés, et autres vulnérabilités issues du Top 10 de l'OWASP et d'autres encore. Cette phase repose sur trois techniques principales :
- Le fuzzing envoie des données inattendues ou malformées pour déclencher des erreurs non gérées.
- Manipulation de paramètres, modification des valeurs dans les URL, les cookies et les corps de requêtes pour tester la validation des entrées
- Tests d'authentification tentant la fixation de session, la prédiction de jeton et l'élévation de privilèges entre les rôles d'utilisateur
- Analyse des réponses : Le scanner évalue chaque réponse afin de détecter des indicateurs de vulnérabilité réelle, tels que des traces de pile, des messages d’erreur de base de données, des redirections vers des ressources non prévues ou des données renvoyées dont l’accès devrait être contrôlé. Les outils utilisant l’analyse basée sur les preuves confirment l’exploitabilité avant de signaler un problème, ce qui réduit les faux positifs.
- Rapports : Les résultats sont compilés dans un rapport classé par niveau de gravité, indiquant le terminal concerné, la charge utile à l’origine du problème et des recommandations de correction. La plupart des outils d’analyse d’entreprise exportent directement les résultats vers Jira, GitHub Issues ou les plateformes SIEM, permettant ainsi d’acheminer les résultats vers l’équipe compétente sans intervention manuelle.
- Tests de validation : une fois le correctif déployé, l’analyseur est relancé sur le point de terminaison précédemment vulnérable afin de confirmer que la vulnérabilité est corrigée, une étape qui sert également de preuve documentée pour les audits de conformité.
Les 7 principaux cas d'utilisation de DAST
1-Intégration au cycle de vie du développement
L'analyse statique de données (DAST) s'intègre aux phases de test et de préproduction du cycle de vie du développement logiciel, lorsque les applications sont exécutées mais pas encore en production. À ce stade, les vulnérabilités sont moins coûteuses à corriger et ne présentent aucun risque pour le client. Dans les pipelines CI/CD, les analyses peuvent être déclenchées automatiquement à chaque compilation, faisant de la sécurité une étape régulière du processus de déploiement plutôt qu'une étape finale.
Exemple concret
Avant l'intégration, l'équipe de sécurité effectuait des analyses manuelles qui ne permettaient pas de suivre le rythme des déploiements de Park 'N Fly. Après avoir connecté Invicti à leurs flux de travail Azure DevOps et Jira existants, les analyses se déclenchent automatiquement à chaque build, déplaçant ainsi les contrôles de sécurité d'une revue trimestrielle à une validation par version. L'équipe a ainsi récupéré l'équivalent de la charge de travail manuelle d'un employé à temps plein. 2
2-Simulation d'attaque en monde réel
Les outils DAST simulent des attaques réelles sur une application web, fournissant une évaluation pratique de son niveau de sécurité.
Exemple concret
En mai 2023, une faille de sécurité par injection SQL dans la plateforme MOVEit Transfer de Progress Software, une application de transfert de fichiers gérés largement utilisée, a été exploitée avant même que l'éditeur n'en prenne connaissance. Cette brèche a compromis 11,3 millions de dossiers patients chez Maximus et a affecté des dizaines d'organismes gouvernementaux et d'entreprises dans plusieurs pays, dont la BBC, l'éditeur britannique de logiciels RH Zellis et le gouvernement de la Nouvelle-Écosse. 3
Progress Software n'a découvert la vulnérabilité qu'après avoir été victime d'une attaque active. L'entreprise l'a confirmée, a publié un correctif et a averti ses clients le jour même, mais l'exploitation avait déjà commencé avant que la faille ne soit divulguée. 4
Un scanner DAST exécuté sur l'application web de MOVEit dans un environnement de test aurait injecté des requêtes SQL dans les champs de saisie de l'application et signalé la réponse anormale de la base de données, selon la même technique utilisée par les attaquants. À ce stade, la correction relève du développement. Sans ce test, cette même faille aurait pu affecter un système de production utilisé par des centaines d'organisations.
3- Exigences de conformité et réglementaires
Les réglementations telles que PCI DSS, HIPAA et RGPD exigent des tests de sécurité réguliers pour les applications traitant des données sensibles. Le mot clé est « démontrer » : les auditeurs exigent des preuves documentées que les vulnérabilités ont été identifiées et corrigées, et non une simple confirmation de la réalisation des tests. DAST fournit précisément cela : les rapports d’analyse indiquent quelles vulnérabilités existaient dans l’application en production, à quelle date elles ont été détectées et si leur correction a été vérifiée.
- Les organisations doivent protéger leurs applications web publiques par des évaluations de vulnérabilité périodiques ou un pare-feu applicatif web (WAF). DAST répond à ce besoin d'évaluation en testant l'application déployée contre les vecteurs d'attaque recherchés par les auditeurs (injection SQL, XSS, failles d'authentification) et en générant des rapports horodatés et prêts pour l'audit.
- Les organisations doivent effectuer des contrôles automatisés hebdomadaires afin de détecter toute modification non autorisée des scripts et en-têtes HTTP des pages de paiement. Les rapports d'analyse DAST (Dynamic Security Analysis) appuient cette démarche en fournissant des preuves continues, au niveau de la couche applicative, que l'environnement global des pages de paiement n'a pas été compromis.
Exemple concret
Channel 4, le groupe audiovisuel public britannique, exploite la plateforme de streaming All 4, qui compte 24 millions d'utilisateurs inscrits, tous soumis aux exigences de sécurité des données du RGPD. Afin de démontrer sa conformité, l'équipe de sécurité commandait auparavant plusieurs tests d'intrusion externes pour chaque projet. Chaque test révélait des anomalies, l'équipe les corrigeait, puis finançait un nouveau test. Brian Brackenborough, RSSI, a décrit le coût cumulatif de ce processus : chaque projet pouvait nécessiter plusieurs cycles en fonction de sa complexité.
Après l'intégration de la plateforme DAST automatisée d'Invicti, Channel 4 est passé à une analyse continue à des étapes clés de ses projets, remplaçant ainsi le cycle de tests répétés par une vérification automatisée interne. Les dépenses annuelles en tests d'intrusion ont diminué d'environ 60 % la première année et sont tombées à environ 20 % des dépenses initiales la deuxième année. 5
4-Couverture complète
DAST teste chaque interface exposée par l'application aux formulaires de connexion externes, aux jetons de session, aux points de terminaison d'API, aux paramètres d'URL et aux en-têtes HTTP, sans accéder au code source. Les failles d'authentification, la fixation de session, les références directes non sécurisées aux objets et les contrôles d'accès mal configurés ne constituent pas des modèles statiques dans le code ; elles résultent du comportement de l'application lorsqu'un utilisateur ou un attaquant lui envoie des entrées spécifiques.
DAST couvre les points de terminaison que les développeurs n'ont peut-être pas exposés intentionnellement. Les API fantômes, les routes obsolètes restées actives après une modification de fonctionnalité et les interfaces d'administration accessibles depuis le réseau public n'apparaîtront pas lors d'une revue de code, mais seront détectées lors d'une analyse DAST.
5- Surveillance continue
Les applications ne restent pas figées après leur déploiement. Les bibliothèques sont mises à jour, de nouveaux points de terminaison sont ajoutés, des modifications de configuration sont apportées et des scripts tiers sont chargés depuis des domaines externes ; autant d’actions susceptibles d’introduire une vulnérabilité non détectée lors de la dernière analyse. Les tests annuels ou trimestriels ne permettent pas de déceler une faille introduite lors d’un déploiement effectué un mardi. L’analyse DAST intégrée à un pipeline CI/CD s’exécute sur chaque nouvelle version, ce qui garantit une vérification continue de la sécurité de l’application.
Les dépendances tierces rendent cette approche particulièrement cruciale. Les attaques de la chaîne d'approvisionnement, où un composant externe de confiance est compromis et utilisé pour injecter des comportements malveillants dans des applications en aval, figurent désormais au troisième rang des risques les plus importants pour les applications web dans le Top 10 de l'OWASP de 2025. L'analyse statique du code (DAST) détecte ces attaques lors de l'exécution, là où le comportement injecté se manifeste réellement, et non dans le code source où la dépendance peut sembler inchangée.
Exemple concret
En juin 2024, le nom de domaine et le dépôt GitHub de Polyfill.js ont été acquis par un nouveau propriétaire qui a modifié le script afin de rediriger les utilisateurs mobiles vers des sites malveillants. Plus de 100 000 applications web chargeaient Polyfill directement depuis le CDN, transformant ainsi une dépendance de confiance en vecteur d'attaque sans que le code source de ces applications ne soit modifié. Les outils DAST ont rapidement détecté ce comportement malveillant, identifiant les applications qui chargeaient le script compromis et générant des recommandations exploitables pour la correction des vulnérabilités. 6
6-Identification des problèmes d'exécution
Certaines vulnérabilités n'existent pas dans le code source ; elles émergent du comportement d'une application déployée en conditions réelles. Les conditions de concurrence apparaissent lorsque des requêtes simultanées accèdent à la même ressource. Les failles de logique métier se manifestent lorsqu'un attaquant parcourt un flux de travail à plusieurs étapes dans le mauvais ordre. La falsification de requêtes côté serveur (SSRF) ne se manifeste que lorsque l'application établit activement des connexions sortantes vers d'autres systèmes. Les fuites de mémoire, les échecs de délai d'expiration de session et la désérialisation non sécurisée nécessitent toutes une application en production pour se déclencher.
DAST aborde ces problèmes en interagissant avec l'application exactement comme le ferait un utilisateur ou un attaquant, en envoyant des entrées, en observant les réponses et en testant le comportement du système dans des conditions que l'analyse statique ne peut pas simuler.
7- Complément aux autres méthodes d'essai
Aucune méthode de test ne couvre à elle seule l'intégralité de la surface d'attaque d'une application moderne. Les équipes de sécurité combinent généralement le DAST avec :
- L'analyse statique du code source (SAST) examine le code source avant le déploiement, détectant ainsi les problèmes tels que les secrets codés en dur, les appels de fonctions non sécurisés et les concaténations de chaînes vulnérables aux injections, et ce dès les premières étapes du développement. Elle ne permet cependant pas de tester le comportement à l'exécution.
- IAST instrumente l'application de l'intérieur pendant son exécution, en surveillant le flux de données à travers le code. Alors que DAST observe le comportement externe de l'application, IAST observe son comportement interne lors d'une même requête ; les deux méthodes produisent des résultats complémentaires, issus de points de vue opposés.
- SCA analyse les bibliothèques tierces et open source à la recherche de vulnérabilités connues (CVE), signalant les dépendances vulnérables avant leur mise en production. L'incident Polyfill illustre cette lacune : SCA n'aurait pas détecté l'attaque car la bibliothèque elle-même ne présentait aucune vulnérabilité connue (CVE) au moment où le domaine l'hébergeant a été compromis. DAST a, quant à lui, détecté le comportement malveillant à l'exécution que SCA n'a pas pu identifier.
- Les scanners de réseau et de vulnérabilités identifient les ports ouverts, les services obsolètes et les erreurs de configuration d'infrastructure au niveau de l'hôte et du réseau, en dessous de l'application elle-même.
Limitations à prendre en compte lors de l'utilisation de DAST
1. Aucune visibilité sur le code interne
L'analyse DAST teste les points de terminaison, formulaires, en-têtes et réponses exposés par l'application. Elle ne peut pas lire le code source ; par conséquent, les vulnérabilités qui ne se manifestent jamais par une interaction externe restent indétectées. Par exemple, une authentification codée en dur et dissimulée dans la logique côté serveur n'apparaîtra pas lors d'une analyse DAST, sauf si elle produit une réponse observable. L'analyse SAST ou une revue de code est alors nécessaire pour les détecter.
2. Découverte en phase tardive
L'analyse statique de données (DAST) nécessite une application en cours d'exécution ; elle ne peut donc être utilisée qu'en phase de test ou de préproduction. Une vulnérabilité introduite en début de développement peut survivre à plusieurs cycles de compilation avant d'être détectée par une analyse DAST. Plus une vulnérabilité est découverte tardivement, plus le code développé s'est étendu par-dessus, augmentant ainsi le coût de la correction et le risque qu'un correctif engendre de nouveaux problèmes.
3. Faux positifs et faux négatifs
Les outils DAST déduisent les vulnérabilités des réponses des applications, ce qui signifie qu'ils peuvent signaler un comportement anodin comme une vulnérabilité (faux positif) ou ne pas détecter une vulnérabilité nécessitant une séquence d'entrées spécifique (faux négatif). Les faux positifs entraînent une perte de temps pour la correction ; les faux négatifs créent un faux sentiment de sécurité. Les outils modernes réduisent les faux positifs grâce à une analyse basée sur des preuves, confirmant l'exploitabilité d'une vulnérabilité avant de la signaler, mais des lacunes persistent, notamment dans les flux de travail complexes nécessitant une authentification.
4. Défauts de logique métier
DAST identifie les vulnérabilités qui produisent des anomalies détectables telles que les injections SQL, les attaques XSS et les contournements d'authentification. Il ne peut cependant pas détecter les failles où l'application se comporte exactement comme prévu, mais où la logique elle-même est vulnérable. En 2026, les violations d'autorisation au niveau objet (BOLA) et au niveau fonction (BFLA) constituent les principaux risques de sécurité des API ; ces deux problèmes impliquent que l'application traite correctement une requête qu'elle aurait dû rejeter. Aucun outil d'analyse automatisée ne peut déterminer qu'une règle métier est erronée, mais seulement qu'elle a été enfreinte.
5. Risque lié à l'analyse de la production
DAST envoie activement des charges utiles d'attaque à une application en production. En environnement de test, ce comportement est normal. En production, la même analyse peut déclencher des erreurs, corrompre des données de test, bloquer des comptes ou générer une charge qui dégrade les performances pour les utilisateurs. La plupart des équipes limitent les analyses DAST complètes aux environnements de préproduction et utilisent une surveillance passive plus légère en production, acceptant ainsi une couverture incomplète au profit de la sécurité opérationnelle.
6. Aucune localisation au niveau du code
L'analyse statique de données (DAST) identifie une vulnérabilité à un point de terminaison donné, mais ne permet pas d'identifier la ligne de code responsable. Un développeur recevant un résultat DAST doit reproduire le problème, suivre la requête à travers la pile applicative et localiser manuellement la source. L'intégration des résultats DAST avec ceux de l'analyse statique de données (SAST) ou l'utilisation d'une analyse statique de données intégrée (IAST), qui instrumente l'application de l'intérieur, permet de réduire cet écart en corrélant le résultat d'exécution avec un emplacement précis dans le code.
7. Lacunes de couverture dans les architectures d'applications modernes
Un outil DAST explore une application en suivant les liens et en soumettant des formulaires. Les applications monopages développées avec React, Angular ou Vue génèrent du contenu dynamiquement via JavaScript après le chargement initial de la page, ce que les robots d'exploration traditionnels ne peuvent pas explorer entièrement. Les API nécessitant des jetons d'authentification spécifiques, des flux de travail en plusieurs étapes ou des formats d'entrée non standard peuvent également ne pas être testées, sauf si l'outil DAST est explicitement configuré pour elles. La couverture est exhaustive dans la mesure où l'outil d'exploration peut naviguer dans l'application.
FAQ
Les tests de sécurité dynamiques des applications (DAST) analysent une application en cours d'exécution de l'extérieur, sans accéder à son code source. Ils envoient des entrées malveillantes, des injections SQL, des chaînes XSS et des tentatives de contournement d'authentification aux interfaces exposées, et signalent les réponses inattendues comme des vulnérabilités potentielles. Fonctionnant exactement comme un attaquant externe, les tests DAST détectent les failles qui n'apparaissent qu'à l'exécution et que l'analyse statique du code ne permet pas de déceler.
Dans les pratiques modernes de développement logiciel, notamment celles qui suivent les méthodologies DevOps, les bonnes pratiques et les outils DAST peuvent être intégrés aux pipelines d'intégration continue et de déploiement continu (CI/CD). Cette intégration garantit une sécurité continue tout au long du cycle de vie de l'application.
Pour choisir un outil DAST, consultez la liste des meilleures solutions DAST .
Les outils DAST, les outils d'analyse des vulnérabilités, les outils de sécurité des API et les outils de sécurité des applications servent des objectifs spécifiques dans le contexte plus large de la cybersécurité, même s'il existe un certain chevauchement.
Les outils DAST sont spécialisés dans le test de la sécurité des applications web pendant leur exécution, en simulant des attaques externes pour déceler les vulnérabilités qui ne sont apparentes que pendant leur fonctionnement.
Les outils d'analyse des vulnérabilités offrent un service plus étendu, en analysant les systèmes, les réseaux ou les applications afin de détecter divers problèmes de sécurité, y compris les faiblesses qui ne se limitent pas au logiciel lui-même, mais qui peuvent concerner des configurations ou des systèmes obsolètes.
Les outils de sécurité des API sont spécifiquement conçus pour protéger les API, interfaces essentielles entre différentes applications logicielles. Ces outils se concentrent sur les problématiques de sécurité propres aux API, telles que la sécurisation des points de terminaison, l'authentification et la gestion des appels d'API, et la garantie de l'intégrité des données lors de leur transmission.
Les outils de sécurité applicative englobent une vaste gamme d'outils, y compris ceux mentionnés ci-dessus, et visent à sécuriser les applications tout au long de leur cycle de vie. Cette catégorie comprend des outils et des pratiques qui abordent la sécurité à différentes étapes, du développement au déploiement et à la maintenance.
Ces catégories se recoupent toutefois :
Les outils DAST sont un sous-ensemble d'outils de sécurité applicative, spécifiquement conçus pour identifier les vulnérabilités des applications web en production grâce à des attaques externes simulées.
Les outils de sécurité des API relèvent également de la catégorie plus large des outils de sécurité des applications, mais ils se concentrent spécifiquement sur la sécurité des interfaces API, répondant à des défis uniques tels que la sécurité des points de terminaison et l'authentification.
Les outils d'analyse de vulnérabilités ont un champ d'application plus large, englobant les contrôles de sécurité de systèmes entiers, y compris les réseaux et les applications. Ils intègrent souvent des fonctionnalités permettant d'identifier les vulnérabilités des applications web et des API, recoupant ainsi les outils DAST et de sécurité des API.
Liens de référence
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.