DAST (Dynamic Application Security Testing).

Les outils DAST interagissent avec une application déployée — typiquement en HTTP — sans nécessiter de code source. Ils explorent les endpoints, envoient des requêtes spécialement formées et observent les réponses pour détecter injection SQL, XSS, SSRF, authentification cassée, CORS mal configuré ou cookies non sécurisés. Voyant ce qu'un attaquant voit, le DAST complète le SAST en capturant des problèmes purement runtime, y compris ceux issus de la configuration, de l'infrastructure ou de services tiers. Il s'exécute en staging ou QA et s'intègre au CI/CD comme porte de livraison. Outils répandus : OWASP ZAP, Burp Suite, Invicti, Acunetix, StackHawk.

Comment ça fonctionne

Un scan DAST se déroule en deux phases. D'abord, un crawler (spider) cartographie la surface d'attaque de l'application en suivant les liens, en analysant le JavaScript et en rejouant le trafic enregistré pour découvrir formulaires, paramètres et routes d'API. Ensuite, un scanner actif mute chaque entrée avec des charges utiles d'attaque et déduit les vulnérabilités à partir des codes de réponse, du timing, du contenu réfléchi ou des signatures d'erreur — par exemple, une injection SQL en aveugle basée sur le temps est confirmée lorsqu'une charge SLEEP() retarde la réponse de façon mesurable.

Le DAST moderne s'est orienté vers le scan API-first et authentifié : les applications monopages et les back-ends REST/GraphQL exposent peu de choses à un crawler naïf, si bien que les scanners consomment les spécifications OpenAPI/Swagger et utilisent des séquences de connexion scriptées pour atteindre les fonctionnalités protégées. La couverture est couramment évaluée par rapport à l'OWASP Web Security Testing Guide (WSTG). Les limites du DAST comptent tout autant : il ne fournit aucune localisation au niveau de la ligne de code, ne voit pas les chemins de code inatteignables et risque des faux négatifs sur des états côté client complexes — c'est pourquoi les équipes l'associent au SAST et à l'IAST plutôt que de s'y fier seul. Pour éviter de scanner la production et de déclencher de véritables effets de bord (envoi d'e-mails, passage de commandes), les scans sont cantonnés à des cibles hors production et dotés d'un périmètre défini et d'une liste d'exclusion.

flowchart LR
  A[Application en cours<br/>staging/QA] --> B[Crawler / spider<br/>cartographie les endpoints]
  B --> C[Scanner actif<br/>injecte des charges utiles]
  C --> D{Anomalie dans<br/>la réponse ?}
  D -->|Oui| E[Signaler la découverte<br/>SQLi / XSS / SSRF]
  D -->|Non| F[Marquer l'endpoint sain]
  E --> G[Porte CI/CD<br/>échec du build / triage]