Qu'est-ce qu'un DAST : fonctionnement, outils 2026

Un DAST (Dynamic Application Security Testing, littéralement « test dynamique de sécurité applicative ») est un outil de test de sécurité qui analyse une application en cours d'exécution — le runtime, pas le code source — en envoyant des requêtes HTTP réelles et en analysant les réponses pour y détecter des vulnérabilités. Il simule le comportement d'un attaquant externe qui sonde l'application depuis l'extérieur, sans accès au code : crawl du site, injection de payloads dans les paramètres, headers et cookies, analyse statistique des réponses, mesure du temps de réponse pour détecter les injections blind, replay de requêtes modifiées pour détecter les bypass. Le DAST est positionné en fin de pipeline CI/CD (après déploiement sur environnement de test ou staging) et couvre efficacement les vulnérabilités OWASP Top 10 Web observables via HTTP : injection SQL, XSS reflected et DOM-based, SSRF, Path Traversal, misconfiguration (headers manquants, cookies sans Secure/HttpOnly, CORS trop permissif), verbose errors, exposure de fichiers sensibles. Il complète sans remplacer SAST (analyse de code source), IAST (agent runtime observant les flux de données) et SCA (scan des composants tiers). Outils dominants 2026 : OWASP ZAP (open source, maintenu par Checkmarx depuis mai 2024), Burp Suite Enterprise (PortSwigger), StackHawk, Invicti, Checkmarx DAST, Rapid7 InsightAppSec, Qualys WAS, HCL AppScan. Cet article détaille le fonctionnement du DAST, ses forces et limites, les outils leaders 2026, l'intégration CI/CD, et son positionnement dans l'architecture AppSec complète.

1. Le principe du DAST

1.1 Test dynamique vs test statique

Deux approches historiques en AppSec, nées dans les années 2000-2010 :

• SAST (Static Application Security Testing) : analyse du code avant son exécution. L'outil parse les fichiers source (ou binaires décompilés), construit un AST (Abstract Syntax Tree) et un graphe de flux de données, cherche des patterns dangereux (taint analysis, data flow analysis). Exemples : Semgrep, CodeQL, SonarQube, Checkmarx SAST, Fortify.
• DAST : analyse de l'application pendant son exécution. L'outil envoie des requêtes HTTP, observe les réponses, ne connaît pas le code. Exemples : OWASP ZAP, Burp Suite, Invicti, StackHawk, Checkmarx DAST.

Le DAST a un point de vue extérieur boîte noire : il voit ce qu'un attaquant externe voit, ni plus, ni moins.

1.2 Analogie concrète

SAST = un architecte qui inspecte les plans de ta maison et pointe les failles structurelles théoriques (mur porteur trop fin, escalier trop étroit).

DAST = un cambrioleur bienveillant qui essaie toutes les fenêtres et toutes les portes de ta maison construite, et te dit lesquelles s'ouvrent sans effort.

Les deux sont utiles. Le cambrioleur bienveillant trouve des failles réellement exploitables mais rate tout ce qui n'est pas accessible depuis l'extérieur.

2. Comment fonctionne un DAST

2.1 Les 4 phases d'un scan DAST

Un scan DAST typique suit 4 phases séquentielles :

1. Discovery / Crawling : l'outil explore l'application pour cartographier les URLs, endpoints, paramètres, formulaires. Technique classique (BFS ou DFS sur les liens HTML) complétée par l'import d'une spec OpenAPI/Swagger pour les APIs ou l'enregistrement d'un flow utilisateur via navigateur headless (Chromium/Playwright).
2. Authentication : l'outil se connecte à l'application avec un compte de test fourni, via un flow enregistré ou un token réutilisé. Essentiel pour couvrir les parties internes de l'application.
3. Active scanning : l'outil envoie des payloads d'attaque sur chaque paramètre identifié — strings SQL, XSS, command injection, path traversal, XXE, SSRF, variations sur les headers. Il compare les réponses (content-length, status code, timing, pattern dans le body) pour détecter les anomalies révélatrices.
4. Reporting : consolidation des findings, déduplication, scoring CVSS, génération du rapport (JSON, SARIF, HTML, PDF).

2.2 Exemple : détection d'une SQL injection

# exemple-zap-baseline-scan.sh
# Scan DAST minimal avec OWASP ZAP baseline scan (Docker).
# Baseline = passif + quelques actifs safe, execution ~5-15 min.
# Cible : environnement de test isolé, jamais production.
 
docker run --rm \
  -v $(pwd):/zap/wrk/:rw \
  -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t https://staging.app.example.test \
  -r baseline-report.html \
  -J baseline-report.json \
  -I              # ne pas faire echouer le CI sur les warnings
  -j              # spider AJAX pour SPA
 
# Exit code :
#   0 = aucune alerte
#   1 = alertes WARN
#   2 = alertes FAIL (sevère)
# Utilise en CI avec -I pour reporter les warnings sans bloquer,
# sans -I pour bloquer sur High/Critical.

Pour une SQLi, le DAST envoie sur chaque paramètre un ensemble de payloads et compare :

• Payload ' → si la réponse contient SQL syntax error, indice fort de SQLi error-based.
• Payload ' OR '1'='1 → si le content-length ou le nombre de résultats change, indice d'injection boolean-based.
• Payload '; WAITFOR DELAY '0:0:5' -- → si la latence passe de 200 ms à 5 s, confirmation time-based blind SQLi.

2.3 Passif vs actif

Deux modes distincts :

• Scan passif : l'outil n'envoie pas de payload, il observe simplement le trafic existant (généré par des tests fonctionnels, par exemple). Détecte les misconfigurations visibles dans les headers (absence HSTS, CSP faible), les cookies sans flags, les informations exposées. Zéro risque, zéro faux positif sur ce qu'il rapporte, mais couverture limitée.
• Scan actif : l'outil envoie des payloads offensifs. Détecte bien plus mais introduit un risque de DoS sur l'application cible et de corruption de données si lancé sur un environnement non isolé.

Règle opérationnelle 2026 : scan passif autorisé sur pre-prod avec trafic de test, scan actif jamais sur production, toujours sur environnement dédié avec données synthétiques.

3. Ce que le DAST détecte bien et ce qu'il rate

3.1 Catégories bien couvertes

3.2 Ce que le DAST rate systématiquement

• Logique métier : IDOR, BOLA, BFLA, race conditions, workflows bypass. Un scanner automatique ne comprend pas que /api/invoices/42 et /api/invoices/43 sont sémantiquement liés.
• Stored XSS nécessitant un workflow complexe (créer un objet, le valider, le partager avec un autre user, l'afficher).
• Chaînes d'exploitation : compromettre via finding A, pivoter via finding B, atteindre l'objectif via finding C.
• Vulnérabilités sous conditions : trigger uniquement le 31 du mois, uniquement avec rôle X, uniquement après 5 échecs consécutifs.
• Features non crawlées : le scanner ne trouve pas l'endpoint si aucun lien vers lui n'existe et qu'il n'est pas dans la spec fournie.

Taux de couverture empirique : un DAST bien configuré couvre 40 à 60 % des findings d'un pentest humain équivalent sur une application web classique. D'où la nécessité de ne jamais remplacer un pentest par un DAST seul.

4. Le paysage 2026 : DAST vs SAST vs IAST vs SCA

Quatre familles d'outils AppSec se complètent dans une architecture defense-in-depth moderne.

4.1 Recommandation d'architecture 2026

Stack AppSec pipeline recommandée par couche :

# pipeline-appsec-stack-2026.yml
# Architecture de reference AppSec en pipeline CI/CD.
# Chaque couche couvre un angle distinct, combinees elles atteignent ~85 % de couverture.
 
pre_commit:
  secret_scan: "gitleaks, trufflehog"
  linter_security: "ESLint plugin security, Bandit pour Python"
 
ci_early_pull_request:
  sast:
    outils: ["Semgrep", "CodeQL", "SonarQube"]
    duree_typique: "2-10 min"
    blocage: "HIGH ou CRITICAL block merge"
  sca:
    outils: ["Snyk", "Dependency-Track", "Dependabot"]
    duree_typique: "1-3 min"
    blocage: "CVSS >= 9 block, >= 7 require ticket"
  iac_scan:
    outils: ["tfsec", "Checkov", "Trivy IaC"]
    duree_typique: "1-3 min"
 
ci_integration_deploy_staging:
  container_scan:
    outils: ["Trivy", "Grype"]
    duree_typique: "2-5 min"
  dast_baseline:
    outils: ["OWASP ZAP baseline"]
    duree_typique: "5-15 min"
    mode: "passif + active safe"
    blocage: "HIGH block deploy, MEDIUM ticket"
 
nightly_weekly:
  dast_full:
    outils: ["OWASP ZAP full, Burp Enterprise, StackHawk"]
    duree_typique: "1-8 heures"
    mode: "active scan complet avec authentification"
    rapport: "tickets Jira auto-crees par severite"
  iast:
    outils: ["Contrast Security, Seeker (Synopsys), HCL AppScan Intelligent Finding Analytics"]
    mode: "agent pendant tests e2e, correlation flux"
 
production:
  rasp_waf:
    outils: ["Cloudflare, AWS WAF + OWASP CRS 4.0, Imperva"]
  siem:
    detection: "MITRE ATT&CK, custom rules"
  bug_bounty:
    plateformes: ["YesWeHack, HackerOne, Intigriti"]

5. Outils DAST dominants 2026

5.1 Open source

OWASP ZAP (Zed Attack Proxy) : historiquement le projet phare OWASP depuis 2010, transféré en gouvernance Checkmarx en mai 2024. Gratuit, multi-plateforme, extensible via scripts Zest/Python/JavaScript/Groovy. Deux modes CI : zap-baseline.py (passif + safe actifs, 5-15 min) et zap-full-scan.py (complet, 1-4 heures). Support natif OpenAPI/Swagger import, GraphQL via add-on. Adoption dominante en startup, scale-up et contextes open source strict.

OWASP Nettacker : plus récent, scanner multi-module, moins mature que ZAP mais positionné en complément.

5.2 Commercial

5.3 Critères de choix 2026

Grille de décision pragmatique :

6. Intégration CI/CD : patterns 2026

6.1 Pattern 1 : Baseline scan à chaque PR

Le plus répandu. Scan passif + actif safe, durée 5-15 min, bloque le merge si finding HIGH/CRITICAL. Exemple pour GitHub Actions avec ZAP :

# .github/workflows/dast-baseline.yml
# Scan DAST baseline automatise a chaque pull request.
# Environnement de test ephemere deploye via preview environment.
 
name: DAST Baseline Scan
 
on:
  pull_request:
    branches: [main]
 
jobs:
  dast-baseline:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Deploy preview environment
        id: preview
        run: |
          # Deployement de l'app en environnement temporaire (exemple Vercel, Railway, Fly.io).
          # Recupere URL publique dans $PREVIEW_URL.
          echo "preview_url=https://pr-${{ github.event.number }}.preview.example.test" >> $GITHUB_OUTPUT
 
      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.14.0
        with:
          target: ${{ steps.preview.outputs.preview_url }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j -T 10'  # -a pour alpha passive rules, -j pour AJAX spider
          allow_issue_writing: false   # pas d'issue GitHub auto, report en artefact uniquement
 
      - name: Upload DAST report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: |
            report_html.html
            report_json.json

6.2 Pattern 2 : Scan complet nocturne

Scan actif complet (1-8 heures) sur environnement staging stable, rapport différé, tickets Jira auto-créés via webhook. Utile en complément du baseline pour découvrir les vulnérabilités non atteintes en mode rapide.

6.3 Pattern 3 : Scan authentifié avec flow enregistré

Pour couvrir les parties internes de l'application (dashboard, admin, workflow utilisateur), enregistrer un flow de login via Burp Suite Enterprise scan launcher, StackHawk ZAP auth config, ou ZAP avec script d'authentification custom. Point critique : renouveler le flow tous les sprints si l'UI change.

6.4 Pattern 4 : DAST API via spec

Pour les APIs REST et GraphQL modernes, le crawling web classique ne fonctionne pas. Pattern recommandé : fournir au scanner une spec OpenAPI 3.x (REST) ou un schéma GraphQL via introspection. Le scanner parse la spec et envoie des payloads ciblés sur chaque endpoint décrit. Outils spécialisés : StackHawk HawkScan, Escape, 42Crunch, Mayhem for API (fuzzing basé spec).

7. Limites, faux positifs et tuning

7.1 Faux positifs typiques

• Réponses 500 sur payload de test : le DAST interprète comme SQLi possible, alors que c'est juste une erreur de validation normale.
• Reflected content : le DAST voit son payload réfléchi sans contexte et signale XSS, alors que l'output est correctement échappé.
• Timing variable : réseau capricieux fait croire à une blind time-based SQLi.
• Fingerprint obsolète : le DAST détecte « Apache 2.2.21 vulnérable à CVE-X » alors que le serveur est patché avec un backport Debian.

7.2 Stratégie de tuning

Protocole de tuning pragmatique en 4 semaines :

1. Semaine 1 : lancer le scan baseline, collecter tous les findings sans filtre.
2. Semaine 2 : valider manuellement les 20 findings top (HIGH/CRITICAL) — estimer ratio vrais/faux positifs.
3. Semaine 3 : configurer les suppressions globales (règles systématiquement bruit, ex: « Cookie sans HttpOnly » sur cookies legitimement lisibles par JS).
4. Semaine 4 : définir le seuil de blocage CI (bloquer sur finding confirmé, warn sur autres).

Objectif : ramener le taux de faux positifs sous 15 % pour maintenir la confiance des développeurs envers le pipeline.

7.3 Limites structurelles

• Pas de shift-left : le DAST intervient après le code. Le feedback boucle est plus long qu'avec SAST (SAST = minutes, DAST = heures).
• Dépend de la qualité du crawl : scanner qui rate 40 % des endpoints = coverage 40 % en moins.
• Besoin d'environnement dédié : coût infra (environnement staging permanent ou éphémère à la demande).
• Risque DoS : un scan actif mal configuré peut saturer l'app cible, générer 1M requêtes en quelques heures.

8. Budget et ROI

Budget indicatif 2026 pour un programme DAST :

ROI : un programme DAST mature détecte 5-15 findings HIGH/CRITICAL par an sur une application de taille moyenne, chacun pouvant coûter 50 k€ à 500 k€ s'ils étaient exploités en production (fuite données, ransomware, amende RGPD). Le break-even est typiquement atteint dès la première année.

Pour approfondir les sujets adjacents, voir introduction OWASP Top 10 pour les vulnérabilités que le DAST tente de détecter, principes secure coding pour la prévention en amont, et la roadmap AppSec pour le parcours d'apprentissage complet.

Points clés à retenir

• DAST = test de sécurité runtime boîte noire, sans accès au code, via requêtes HTTP et analyse des réponses.
• Position pipeline : après déploiement en environnement de test, pas en production.
• Forces : misconfiguration, injection SQL, XSS reflected, SSRF, exposure de fichiers. Détection de vulnérabilités réellement exploitables.
• Limites : rate la logique métier (IDOR, BOLA, business logic), les stored XSS complexes, les chaînes d'attaque multi-étapes. Couvre 40-60 % d'un pentest humain.
• Outils 2026 : OWASP ZAP (open source dominant), Burp Suite Enterprise, StackHawk, Invicti, Checkmarx, Rapid7, Qualys, HCL AppScan.
• Complémentaire : SAST (pre-commit), SCA (dépendances), IAST (précision), RASP (runtime protection). Les 4 ensemble atteignent ~85 % de couverture.
• Intégration CI/CD : baseline scan à chaque PR (5-15 min) + scan complet nocturne (1-8 h).
• APIs modernes : DAST spec-driven (OpenAPI, GraphQL introspection) avec outils dédiés (StackHawk, Escape, 42Crunch).
• DAST ≠ pentest : le DAST automatise les patterns, le pentest humain couvre la logique et les chaînes. Les deux sont nécessaires.