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 :

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

2. Fingerprinting

   L’outil identifie les technologies utilisées : serveur web, framework, CMS, versions. Ces informations orientent les tests à effectuer.

3. 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…

4. 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é.

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

Exemples d’intégration

GitHub Actions

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'

GitLab CI

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

Rappel légal

Scanner un système sans autorisation est un délit pénal en France (art. 323-1 du Code pénal : 3 ans d’emprisonnement, 100 000 € d’amende).

Avant tout scan :

• Obtenir une autorisation écrite du propriétaire
• Ou tester uniquement des systèmes dont vous êtes responsable
• Les programmes de bug bounty fournissent un cadre légal pour les tests

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