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.

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 outil DAST procède généralement en plusieurs phases :

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 :

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 ?

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, 11000+ 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 -t 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 -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py \
  -t https://mon-app.example.com \
  -r zap-full-report.html

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

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).

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

jobs:
  zap-scan:
    runs-on: ubuntu-24.04
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@7cea08522cd386f6c675776d5e4296aecf61f33b # v0.14.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' }}
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - name: Nuclei Scan
        uses: projectdiscovery/nuclei-action@4d91de2768db9fdc7baea9fe5068d6a5b3bffdbc # v2.0.1
        with:
          target: 'https://staging.mon-app.example.com'
          flags: '-severity critical,high'

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:stable
  script:
    - zap-baseline.py -t $CI_ENVIRONMENT_URL -r zap-report.html
  artifacts:
    paths:
      - zap-report.html
  needs:
    - deploy_staging

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

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

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

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

Avantages et limites

Avantages

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

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

Outils disponibles

Nuclei Scanner ultra-rapide basé sur 11000+ 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