DAST : tester la sécurité d'une application en production

En 2019, Capital One subit une fuite de 100 millions de dossiers clients. L'attaquant a exploité une faille SSRF (Server-Side Request Forgery) pour accéder aux métadonnées AWS et récupérer des credentials. Cette vulnérabilité n'aurait pas été détectée par une analyse statique du code, elle nécessitait de tester l'application en cours d'exécution pour être identifiée.

Le DAST (Dynamic Application Security Testing) adopte le point de vue de l'attaquant : il teste l'application déployée pour trouver les failles réellement exploitables.

Ce que vous allez apprendre

Distinguer ce que le DAST détecte de ce que le SAST peut voir.
Choisir entre un scanner automatisé, un moteur à templates et un proxy d'interception selon le besoin.
Lancer un scan OWASP ZAP et un scan Nuclei en ligne de commande.
Brancher un scan DAST après le déploiement en staging, dans GitHub Actions ou GitLab CI.
Trier les résultats et savoir lesquels bloquent réellement une livraison.

Qu'est-ce que le DAST ?

Le DAST (Dynamic Application Security Testing) consiste à tester une application en cours d'exécution pour y détecter des vulnérabilités. L'outil envoie des requêtes malformées, tente des injections, explore les endpoints et analyse les réponses.

C'est un test en boîte noire : le scanner ne connaît pas le code source, il interagit avec l'application comme le ferait un utilisateur, ou un attaquant.

Le DAST répond à la question : "Mon application déployée est-elle vulnérable à des attaques connues ?"

Comment fonctionne un scanner DAST

Un scan DAST enchaîne cinq phases, et la qualité du résultat se joue dès la première. Si le crawling ne découvre que la page d'accueil, les quatre étapes suivantes travailleront sur un périmètre vide et le rapport paraîtra rassurant à tort. C'est pourquoi un scanner mal authentifié, ou bloqué par un formulaire de connexion, produit presque toujours un faux négatif massif.

Crawling (exploration)

Le scanner parcourt l'application pour découvrir les pages, formulaires, endpoints API. Il suit les liens, soumet les formulaires, identifie les points d'entrée.
Fingerprinting

L'outil identifie les technologies utilisées : serveur web, framework, CMS, versions. Ces informations orientent les tests à effectuer.
Fuzzing (injection)

Pour chaque point d'entrée découvert, le scanner injecte des payloads malveillants : caractères spéciaux, scripts XSS, requêtes SQL, commandes système...
Analyse des réponses

L'outil examine les réponses HTTP : codes d'erreur, temps de réponse, contenu retourné. Une réponse anormale peut indiquer une vulnérabilité.
Génération du rapport

Le scanner produit un rapport avec les vulnérabilités trouvées, leur sévérité, les preuves d'exploitation et des recommandations.

Ce que le DAST détecte

Le DAST excelle sur les vulnérabilités exploitables en runtime. Les trois premières catégories du tableau sont détectées de façon fiable et automatique : un scanner sait envoyer une charge d'injection et reconnaître la réponse anormale. Les deux dernières, exposition et logique métier, demandent presque toujours une vérification humaine : un scanner voit qu'une ressource répond, il ne sait pas si l'identifiant demandé appartient bien au compte connecté. Lisez donc ce tableau comme une échelle d'automatisation décroissante, pas comme une liste de garanties.

Catégorie	Exemples	Impact
Injections	SQL, XSS, Command, LDAP	Vol de données, exécution de code
Authentification	Bypass, session fixation, brute force	Usurpation d'identité
Configuration	Headers manquants, TLS faible, CORS permissif	Attaques man-in-the-middle
Exposition	Stack traces, fichiers sensibles, .git exposé	Fuite d'informations
Logique métier	IDOR, mass assignment, race conditions	Accès non autorisé

DAST vs SAST : quelle différence ?

La confusion la plus fréquente consiste à voir ces deux familles comme concurrentes. Elles n'observent pas le même objet : le SAST lit du texte source, le DAST observe un processus qui répond sur le réseau. La ligne qui décide vraiment de votre choix est celle de la couverture : le SAST parcourt tout le code, y compris les branches jamais atteintes, alors que le DAST ne voit que ce que son crawler a réussi à joindre.

Aspect	DAST	SAST
Quand	Application déployée	Pendant le développement
Comment	Test en boîte noire	Analyse du code source
Trouve	Failles exploitables	Failles potentielles
Faux positifs	Moins nombreux	Plus nombreux
Couverture	Chemins exécutés uniquement	Tout le code
Contexte	Runtime, configuration réelle	Code isolé

Le DAST trouve des vulnérabilités que le SAST ne verra jamais (problèmes de configuration, logique métier), et inversement. Les deux sont complémentaires.

Types de scanners DAST

Scanners automatisés (spider + fuzzer)

Ces outils crawlent l'application et testent automatiquement les points d'entrée découverts. Idéal pour les scans réguliers en CI/CD.

Outils recommandés :

Outil	Points forts	Licence
OWASP ZAP	Référence open source, très complet	Open source
Burp Suite	Fonctionnalités avancées, communauté active	Community/Pro
Nikto	Simple, rapide, détection de misconfigs	Open source

Scanners basés sur templates

Ces outils exécutent des tests prédéfinis (templates) contre une cible. Plus rapides, ils détectent des vulnérabilités connues sans crawler l'application.

Outil	Points forts	Licence
Nuclei	Ultra-rapide, plus de 13 000 templates communautaires	Open source
Nmap + scripts NSE	Classique, polyvalent	Open source

Proxies d'interception

Ces outils s'intercalent entre le navigateur et l'application pour capturer, modifier et rejouer les requêtes. Essentiels pour les tests manuels.

Outil	Points forts	Licence
Burp Suite	Standard de l'industrie	Community/Pro
OWASP ZAP	Alternative open source	Open source
mitmproxy	Scriptable en Python	Open source

Outils DAST en détail

OWASP ZAP

ZAP (Zed Attack Proxy) est le scanner DAST open source de référence. Il combine proxy d'interception, spider automatique et scanner de vulnérabilités.

Cas d'usage : scans automatisés en CI/CD, tests manuels, formation.

# Scan baseline automatisé (rapide, non intrusif)
docker run --rm -t -v "$(pwd):/zap/wrk/:rw" ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t https://mon-app.example.com \
  -r zap-report.html

# Scan complet (plus lent, plus approfondi)
docker run --rm -t -v "$(pwd):/zap/wrk/:rw" ghcr.io/zaproxy/zaproxy:stable \
  zap-full-scan.py \
  -t https://mon-app.example.com \
  -r zap-full-report.html

Le montage de /zap/wrk est obligatoire pour récupérer le rapport : sans lui, zap-baseline.py affiche l'avertissement the directory '/zap/wrk' is not mounted et le fichier HTML disparaît avec le conteneur. Le conteneur tourne sous l'utilisateur zap (UID 1000), vérifiez donc que le répertoire courant lui est accessible en écriture.

Modes de scan ZAP :

Mode	Durée	Couverture	Usage
Baseline	Minutes	Headers, config	CI/CD, smoke test
API	Variable	Endpoints OpenAPI	APIs REST
Full	Heures	Complet avec fuzzing	Audit approfondi

Nuclei

Nuclei est un scanner ultra-rapide basé sur des templates YAML. Il ne crawle pas l'application mais exécute des tests ciblés.

Cas d'usage : détection rapide de CVE connues, scans à grande échelle.

# Scanner avec tous les templates
nuclei -u https://mon-app.example.com

# Scanner uniquement les CVE critiques et hautes
nuclei -u https://mon-app.example.com -s critical,high

# Scanner avec des templates spécifiques
nuclei -u https://mon-app.example.com -t cves/ -t exposures/

→ Guide complet Nuclei

Burp Suite

Burp Suite est l'outil de référence pour les pentesters. La version Community est gratuite mais limitée. La version Pro ajoute le scanner automatisé et des fonctionnalités avancées.

Cas d'usage : audits manuels, bug bounty, pentests professionnels.

Intégration dans le pipeline CI/CD

Le DAST s'intègre idéalement après le déploiement en environnement de test.

Architecture type

La position du scan dans la chaîne détermine ce qu'il peut trouver. Placé avant le déploiement, il n'a rien à interroger ; placé après la mise en production, il constate les dégâts trop tard. Le point d'insertion utile est donc juste après le déploiement en staging, sur un environnement dont la configuration est identique à la production.

Code → Build → Deploy (staging) → DAST scan → Deploy (prod)

Le scan DAST s'exécute sur l'environnement de staging, jamais directement en production (risque de perturbation).

Exemples d'intégration

Les deux exemples ci-dessous partagent le même déclencheur : ils attendent la fin du déploiement en staging plutôt que le simple push. C'est la différence entre un scan qui teste la nouvelle version et un scan qui teste l'ancienne. Notez aussi le moindre privilège appliqué au workflow GitHub Actions : permissions: {} coupe le jeton par défaut, chaque job ne rouvre que ce dont il a besoin, et persist-credentials: false évite de laisser un jeton Git utilisable dans le conteneur du runner pendant le scan.

GitHub Actions
GitLab CI

name: DAST Scan
on:
  workflow_run:
    workflows: ["Deploy to Staging"]
    types: [completed]

permissions: {}

jobs:
  zap-scan:
    runs-on: ubuntu-24.04
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    permissions:
      contents: read
      issues: write
    steps:
      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@de8ad967d3548d44ef623df22cf95c3b0baf8b25 # v0.15.0
        with:
          target: 'https://staging.mon-app.example.com'
          rules_file_name: '.zap/rules.tsv'
          fail_action: true

  nuclei-scan:
    runs-on: ubuntu-24.04
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - name: Nuclei Scan
        uses: projectdiscovery/nuclei-action@cc153d0541e1adf8a42bbe31c0a4fb2376147538 # v3.1.1
        with:
          args: '-u https://staging.mon-app.example.com -severity critical,high'

Deux détails coûtent souvent une heure de débogage. L'action ZAP a besoin de issues: write parce qu'elle ouvre par défaut une issue GitHub récapitulant les alertes : passez allow_issue_writing: false si vous préférez retirer cette permission. Et depuis la version 3, l'action Nuclei n'accepte plus les entrées target et flags : tout passe désormais par une seule chaîne args, reprise telle quelle par le binaire.

stages:
  - deploy
  - dast

deploy_staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.mon-app.example.com

zap_scan:
  stage: dast
  image: ghcr.io/zaproxy/zaproxy:2.15.0@sha256:8dc78e39fafc3281ac2cf54eab05c3ea02721a1ea58f1c135f981a57f4e218b1
  script:
    - mkdir -p /zap/wrk
    - zap-baseline.py -t "$CI_ENVIRONMENT_URL" -r zap-report.html
  after_script:
    - cp /zap/wrk/zap-report.html "$CI_PROJECT_DIR/zap-report.html"
  artifacts:
    when: always
    paths:
      - zap-report.html
  needs:
    - deploy_staging

Le détour par /zap/wrk n'est pas une coquetterie : zap-baseline.py écrit ses rapports dans ce répertoire fixe, jamais dans le dossier courant du job. Sans la copie vers $CI_PROJECT_DIR, l'artefact remonte vide. Le after_script sert à récupérer le rapport même quand le scan échoue, c'est-à-dire précisément quand vous en avez besoin.

Stratégie de blocage

Le DAST produit moins de faux positifs que le SAST, mais peut quand même alerter sur des éléments non critiques.

Sévérité	Action	Exemple
Critical	Bloquer le déploiement	Injection SQL confirmée
High	Bloquer sauf exception	XSS réfléchi
Medium	Alerter l'équipe	Header de sécurité manquant
Low/Info	Logger pour revue	Version disclosure

Bonnes pratiques

Préparer l'environnement de test

Un scan DAST envoie des milliers de requêtes anormales. Sans préparation, il déclenche le WAF, sature le rate limiting et réveille l'astreinte pour une fausse attaque. Les quatre points ci-dessous se règlent une fois pour toutes, avant le premier scan, et évitent les incidents qui font abandonner l'outil au bout de deux semaines.

Isoler l'environnement de staging (pas de données de production)
Autoriser les IP des scanners dans le WAF/firewall
Désactiver le rate limiting pour les scans
Prévenir l'équipe ops pour éviter les fausses alertes

Configurer les scanners

La configuration par défaut d'un scanner est faite pour un site public anonyme. Sur une application métier, elle donne un rapport pauvre : le crawler se déconnecte tout seul en cliquant sur logout, puis explore les mêmes pages publiques en boucle. Les deux réglages qui changent réellement le résultat sont l'authentification du scanner et l'exclusion des endpoints destructifs.

Exclure les endpoints sensibles (logout, suppression)
Authentifier le scanner pour tester les zones protégées
Limiter la profondeur de crawl pour éviter les boucles infinies
Définir un scope précis (domaines, chemins autorisés)

Gérer les résultats

Un premier scan complet remonte facilement plusieurs centaines d'alertes, dont une majorité en Low ou Info. Le réflexe qui tue l'adoption de l'outil consiste à vouloir tout traiter dès la première itération. Prenez d'abord les findings Critical et High, rejouez-les à la main pour confirmer l'exploitabilité, puis documentez les faux positifs dans le fichier de règles du scanner pour qu'ils ne reviennent pas au scan suivant.

Trier par sévérité et exploitabilité
Vérifier manuellement les findings critiques
Documenter les faux positifs pour les exclure
Suivre les remédiations dans un outil de tracking

Respecter le cadre légal

Contrairement au SAST, qui lit un dépôt dont vous êtes propriétaire, le DAST attaque un système accessible sur le réseau. Le fait que la cible appartienne à votre employeur ne suffit pas : c'est l'autorisation écrite du responsable du système qui vous protège, et elle doit nommer les URL et la fenêtre de tir. Un scan lancé « pour voir » sur un domaine tiers, même sans dommage, tombe sous le coup du texte rappelé ci-dessous.

Avantages et limites

Avantages

L'argument décisif du DAST tient en une phrase : ce qu'il remonte est observable, avec la requête et la réponse en pièce jointe. Face à une équipe de développement qui conteste un finding, cette preuve d'exploitation coupe court au débat, là où un rapport SAST ouvre une discussion sur la faisabilité réelle du chemin d'attaque.

Réaliste : teste l'application dans son environnement réel
Exploitabilité : trouve des failles réellement exploitables
Agnostique : fonctionne quel que soit le langage/framework
Configuration : détecte les problèmes de déploiement
Formateur : montre concrètement comment un attaquant procède

Limites

La limite la plus dangereuse n'est pas la lenteur, c'est la couverture partielle. Un rapport DAST vert signifie « rien trouvé sur les chemins atteints », pas « application saine ». Mesurez systématiquement le nombre d'URL découvertes par le crawler et comparez-le à ce que vous savez de l'application : un écart important invalide le rapport avant même de lire les alertes.

Tard dans le cycle : coûts de correction plus élevés
Couverture partielle : ne teste que les chemins atteints
Environnement requis : nécessite une application déployée
Impact potentiel : peut perturber l'application (logs, données)
Lenteur : les scans complets prennent du temps

À retenir

Le DAST teste une application en cours d'exécution et ne connaît pas son code source : c'est un test en boîte noire.
Il détecte des failles que le SAST ne verra jamais (configuration TLS, headers, logique métier) et inversement : les deux se complètent.
La couverture dépend entièrement du crawler. Un scanner non authentifié produit un rapport rassurant et faux.
Le scan se branche après le déploiement en staging, jamais directement en production.
OWASP ZAP couvre le crawl et le fuzzing, Nuclei couvre les CVE connues en quelques minutes, Burp Suite reste l'outil des tests manuels.
Scanner un système sans autorisation écrite est un délit pénal, y compris sans dommage constaté.

Outils disponibles

Un seul outil DAST fait aujourd'hui l'objet d'un guide détaillé sur ce site. Nuclei est le meilleur point d'entrée quand vous démarrez : sa base de templates couvre les CVE connues sans configuration, et un scan tient en quelques minutes, ce qui le rend compatible avec un pipeline. OWASP ZAP demande davantage de réglages (authentification, contextes) mais reste indispensable dès que vous voulez explorer une application derrière un login.

Nuclei Scanner ultra-rapide basé sur plus de 13 000 templates communautaires.

Pour aller plus loin

Analyse de code et sécurité applicative, Vue d'ensemble SAST, DAST, SCA
SAST : analyser le code source, Détecter les failles avant le déploiement
SCA : analyser les dépendances, Scanner les composants tiers
Comprendre les CVE, Interpréter les vulnérabilités remontées