Pourquoi OWASP ZAP est l’outil DAST gratuit de référence ?

OWASP ZAP (Zed Attack Proxy) est le scanner DAST (Dynamic Application Security Testing) open source maintenu par la fondation OWASP. Gratuit, scriptable, intégrable en CI/CD GitHub Actions, il détecte les vulnérabilités exploitables en boîte noire : SQLi, XSS, CSRF, headers manquants, configurations TLS faibles. Pour une PME sénégalaise sans budget Burp Suite Pro, ZAP couvre 80 % des scans automatisables — exactement ce que les pentests externes vous factureront sinon 500 000 FCFA.

Installer OWASP ZAP

# macOS
brew install zap

# Linux
sudo snap install zaproxy --classic
# ou: télécharger ZAP-2.15.0-Linux.tar.gz depuis zaproxy.org

# Docker (recommandé pour CI/CD)
docker pull ghcr.io/zaproxy/zaproxy:stable

Scan passif en 2 minutes

docker run --rm -t -v $(pwd):/zap/wrk/:rw \
  ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://example.sn \
  -r rapport-baseline.html

# Le baseline scan est passif (non intrusif) — peut tourner en prod
# Détecte: headers manquants, cookies sans flags, CSP absent, etc.

Scan actif complet

docker run --rm -t -v $(pwd):/zap/wrk/:rw \
  ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py \
  -t https://staging.example.sn \
  -r rapport-full.html \
  -c zap.conf

# Attention: scan actif = envoie des payloads potentiellement destructifs
# À lancer uniquement sur staging avec données de test

Scan d’API avec spec OpenAPI

docker run --rm -t -v $(pwd):/zap/wrk/:rw \
  ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
  -t https://api.staging.example.sn/openapi.json \
  -f openapi \
  -r rapport-api.html \
  -z "-config replacer.full_list(0).description=auth \
      -config replacer.full_list(0).enabled=true \
      -config replacer.full_list(0).matchtype=REQ_HEADER \
      -config replacer.full_list(0).matchstr=Authorization \
      -config replacer.full_list(0).regex=false \
      -config replacer.full_list(0).replacement=Bearer $TOKEN"

Intégration GitHub Actions

name: ZAP Scan
on:
  schedule: [{ cron: '0 4 * * 1' }]  # chaque lundi 4h
  workflow_dispatch:
jobs:
  zap:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: ZAP Baseline
        uses: zaproxy/action-baseline@v0.13.0
        with:
          target: 'https://staging.example.sn'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j'
      - uses: actions/upload-artifact@v4
        with: { name: zap-report, path: report_html.html }

Suppression de faux positifs (rules.tsv)

# .zap/rules.tsv (TAB séparé)
10015   IGNORE  (Incomplete or No Cache-control and Pragma HTTP Header Set)
10020   IGNORE  (X-Frame-Options Header Not Set)  # On utilise CSP frame-ancestors
10038   WARN    (Content Security Policy (CSP) Header Not Set)

Contexte et authentification

# Context JSON pour authentifier avant de scanner
cat > context.xml <<'EOF'
<?xml version="1.0"?>
<configuration>
  <context>
    <name>example-sn-authenticated</name>
    <urlregex>https://staging.example.sn/.*</urlregex>
    <authentication>
      <type>formBasedAuthentication</type>
      <loginurl>https://staging.example.sn/login</loginurl>
      <loginrequestdata>email={%username%}&password={%password%}</loginrequestdata>
      <loggedinindicator>Logout</loggedinindicator>
    </authentication>
    <users>
      <user>test-ci@example.sn/CiPass2026!</user>
    </users>
  </context>
</configuration>
EOF

docker run -v $(pwd):/zap/wrk/ ghcr.io/zaproxy/zaproxy:stable \
  zap-full-scan.py -t https://staging.example.sn -n context.xml -U "test-ci@example.sn"

Top vulnérabilités détectées par ZAP

High / Critical:
- SQL injection, Remote OS Command Injection
- XSS (Reflected et Stored)
- Path traversal
- Sensitive information disclosure (stack traces)

Medium:
- CSRF
- Open redirect
- CSP faible ou absent
- Cookies sans Secure/HttpOnly/SameSite

Low:
- HSTS absent
- X-Content-Type-Options absent
- Server banner trop verbeux

Automation avec scripts Zest

// Script d'auth personnalisé (JavaScript dans ZAP)
var HttpRequestHeader = Java.type("org.parosproxy.paros.network.HttpRequestHeader");
function authenticate(helper, paramsValues, credentials) {
  var msg = helper.prepareMessage();
  msg.setRequestHeader(new HttpRequestHeader(
    "POST " + paramsValues.get("loginUrl") + " HTTP/1.1\r\nContent-Type: application/json\r\n\r\n"));
  msg.setRequestBody(JSON.stringify({
    email: credentials.getParam("email"),
    password: credentials.getParam("password")
  }));
  helper.sendAndReceive(msg);
  return msg;
}
function getRequiredParamsNames() { return ["loginUrl"]; }
function getCredentialsParamsNames() { return ["email","password"]; }

Complémentaires à ZAP

Burp Suite (Community/Pro) : proxy manuel de référence, Repeater, Intruder
Nuclei : templates YAML pour CVE connues, très rapide en CI
sqlmap : spécialisé SQL injection
Nikto : scan web rapide, vulnérabilités de serveur
Trivy : scan d’images Docker et dépendances

Pour explorer plus loin

Sécuriser les API de votre application — défense correspondant à ce que ZAP teste.
Introduction au pentesting éthique — méthodologie autour de l’usage de ZAP.
Sécuriser votre site WordPress — pour traiter les findings ZAP côté défense.
Scanner les vulnérabilités avec Nmap — complément réseau de ZAP web.
Référence officielle : ZAP Documentation et OWASP Web Security Testing Guide.
Compléments : Nuclei (templates CVE), Burp Suite Community (proxy manuel).

Solution d’hébergement pour ce tutoriel

Hostinger accueille un site WordPress, un VPS Linux ou une boutique en ligne sans configuration complexe.

Démarrer chez Hostinger →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Étape 1 : Installer OWASP ZAP

OWASP ZAP, abréviation de Zed Attack Proxy, est un scanner de sécurité applicative web open source maintenu par la fondation OWASP. Il s’installe sur Windows, macOS et Linux à partir du site officiel zaproxy.org. La version stable actuelle nécessite Java 17 ou supérieur ; vérifiez votre version avant le téléchargement. Comptez environ deux cents Mo d’espace disque et trois Go de RAM disponibles pour les scans complets.

Au premier lancement, ZAP propose de générer un certificat racine pour intercepter les flux HTTPS. Acceptez et installez ce certificat dans votre navigateur de test, jamais dans votre navigateur principal. Cette séparation est cruciale parce qu’un certificat ZAP installé partout exposerait vos navigations sensibles à interception. Réservez un profil Firefox dédié uniquement aux scans, et désinstallez le certificat dès la fin de la phase de test.

Étape 2 : Définir le périmètre du scan

Avant tout scan, écrivez sur papier le périmètre exact : quelles URL, quels formulaires, quelles fonctionnalités, quelles exclusions. Un scan ZAP non bordé peut générer des milliers de requêtes parasites contre des sous-domaines tiers, voire déclencher des actions destructrices sur des formulaires de production. Documentez aussi l’autorisation écrite du propriétaire du site : sans accord formel, scanner un site tiers est illégal sous la plupart des juridictions ouest-africaines comme européennes.

Pour vos propres environnements, séparez toujours les cibles de test des environnements de production. Idéalement, montez une copie de pré-production sur un sous-domaine dédié comme staging.exemple.sn et scannez uniquement cette copie. Cette séparation évite les indisponibilités accidentelles et protège vos données clients réelles.

Étape 3 : Configurer le proxy intercepteur

Dans Tools puis Options puis Local Proxies, vérifiez que ZAP écoute sur 127.0.0.1 port 8080. Configurez ensuite votre navigateur de test pour utiliser ce proxy. Sous Firefox, allez dans Settings, Network Settings, Manual proxy configuration, et indiquez 127.0.0.1 port 8080. Naviguez ensuite manuellement sur la cible pendant cinq à dix minutes en activant chaque fonctionnalité importante : connexion, recherche, formulaire de contact, panier, paiement de test.

Approfondissement : installation détaillée OWASP ZAP

OWASP ZAP, abréviation de Zed Attack Proxy, est un scanner de sécurité applicative web open source maintenu par la fondation OWASP. Il s’installe sur Windows, macOS et Linux à partir du site officiel zaproxy.org. La version stable actuelle nécessite Java 17 ou supérieur ; vérifiez votre version avant le téléchargement. Comptez deux cents Mo d’espace disque et trois Go de RAM disponibles pour les scans complets sur un poste de travail standard utilisé à Dakar ou à Abidjan.

Approfondissement : périmètre et cadrage du scan

Approfondissement : configuration avancée du proxy

Cette navigation manuelle permet à ZAP de cartographier l’arborescence réelle, y compris les pages accessibles uniquement après authentification. Sans cette étape, le scan automatisé manquera la moitié des points sensibles. La phase manuelle est aussi l’occasion de repérer visuellement des comportements anormaux qui n’apparaîtront pas dans les rapports automatisés.

Étape 4 : Lancer un scan passif puis actif

ZAP analyse en permanence en passif les requêtes qui passent par son proxy, sans en générer de nouvelles. Cette analyse passive révèle les en-têtes de sécurité manquants, les cookies sans flag Secure ou HttpOnly, les fuites d’information dans les en-têtes Server. Consultez l’onglet Alerts à la fin de la navigation manuelle pour découvrir cette première vague de constats sans aucun risque pour la cible.

Lancez ensuite le scan actif via clic droit sur la racine du site dans l’arborescence puis Attack puis Active Scan. Le scan actif envoie des requêtes malveillantes contrôlées : injections SQL, cross-site scripting, traversées de répertoire, manipulations de paramètres. Comptez de quinze minutes pour un site simple à plusieurs heures pour une application complexe. Ne l’interrompez pas avant la fin pour éviter les rapports incomplets et les angles morts dangereux.

Étape 5 : Lire et hiérarchiser le rapport d’alertes

Une fois le scan terminé, l’onglet Alerts liste toutes les vulnérabilités détectées, classées par sévérité High, Medium, Low, Informational. Cette classification est indicative et nécessite une revue humaine : un Cross-Site Scripting détecté sur une page de panel d’administration interne pèse plus lourd que le même XSS sur une page publique en lecture seule. Pour chaque alerte sérieuse, ouvrez le détail et lisez la requête de test, la réponse, et la solution recommandée.

Ne corrigez pas tout en bloc : hiérarchisez selon la criticité métier des fonctionnalités touchées. Une faille sur le module de paiement passe avant une faille sur la page À propos, même si leur sévérité technique est identique. Cette priorisation orientée métier est le travail humain irremplaçable que ZAP ne peut pas faire à votre place.

Étape 6 : Vérifier les vrais positifs et les faux positifs

ZAP génère parfois des faux positifs, notamment sur les applications avec des règles de validation côté serveur que le scanner ne détecte pas en boîte noire. Pour chaque alerte critique, reproduisez manuellement l’attaque dans un navigateur en utilisant la requête capturée. Si la vulnérabilité se confirme, c’est un vrai positif à corriger en priorité. Sinon, marquez l’alerte comme faux positif dans ZAP pour l’écarter des rapports suivants.

Documentez chaque vérification dans un tableau à quatre colonnes : alerte, statut, preuve de reproduction, action décidée. Ce tableau devient le pilote de votre plan de remédiation et la trace d’audit que vos clients ou partenaires vous demanderont en cas de certification ou de réponse à appel d’offres exigeant des standards de sécurité.

Étape 7 : Corriger en suivant les recommandations OWASP

Pour chaque vrai positif, ZAP fournit un lien vers la page de référence OWASP correspondante. Suivez systématiquement cette documentation avant d’inventer une correction maison. Les patterns OWASP sont éprouvés sur des millions d’applications. Pour une injection SQL, la correction canonique est l’utilisation de requêtes préparées avec paramètres typés. Pour un XSS, l’échappement contextuel à la sortie selon le contexte HTML, attribut ou JavaScript.

Une faille est rarement isolée : si ZAP en trouve cinq sur un module, il y en a probablement d’autres que le scanner n’a pas détectées. Faites une revue de code humaine du module concerné après chaque vague de corrections pour traquer les variantes silencieuses, en complément de votre posture sécurité globale.

Étape 8 : Automatiser les scans réguliers en CI/CD

ZAP s’intègre dans une chaîne d’intégration continue via son API REST ou via les actions GitHub officielles. Configurez un scan hebdomadaire automatisé qui s’exécute sur votre environnement de pré-production et publie un rapport HTML dans un canal Slack interne. Cette automatisation détecte les régressions de sécurité dès leur introduction, bien avant qu’elles n’atteignent la production. Le coût d’une faille corrigée en pré-production est environ dix fois inférieur à celui d’une faille corrigée après un incident.

Configurez le pipeline pour bloquer le déploiement en production en cas de nouvelle alerte critique détectée. Cette barrière automatique force la discipline de correction avant mise en ligne et institutionnalise la sécurité dans le cycle de vie applicatif. Les éditeurs sénégalais et ivoiriens qui appliquent cette discipline réduisent leur fréquence d’incidents de sécurité publics de plus de soixante-dix pour cent en deux ans.

Étape 9 : Compléter ZAP par d’autres outils gratuits

ZAP excelle sur les vulnérabilités applicatives mais ne couvre pas tout. Complétez par Nikto pour les configurations serveur, par sslyze pour la qualité TLS, par Wapiti pour une seconde opinion automatisée, et par les en-têtes testés sur securityheaders.com. Cette pile gratuite couvre quatre-vingt-dix pour cent des vérifications qu’un audit professionnel facturé plusieurs millions de FCFA effectuerait à Dakar ou Abidjan.

Documentez chaque outil dans un runbook interne avec sa commande type et l’interprétation de ses sorties, en lien avec votre audit concurrentiel régulier. Ce runbook devient un manuel de sécurité applicative concret, transmissible aux nouveaux développeurs sans dépendre d’un consultant externe coûteux.

Étape 10 : Maintenir une discipline de revue trimestrielle

Bloquez chaque trimestre une demi-journée pour relire vos rapports ZAP successifs, suivre l’évolution du nombre d’alertes par sévérité, et prioriser les remédiations restantes. Cette routine empêche l’accumulation silencieuse de petites failles qui finissent par former un terrain favorable à une attaque réussie. Tenez un journal des décisions de remédiation et de leur impact mesuré pour transformer cette discipline en actif documentaire transmissible aux successeurs.

La sécurité applicative se construit ligne par ligne, alerte par alerte, trimestre par trimestre. Un site qui maintient ce rythme pendant trois ans atteint un niveau de robustesse que les concurrents amateurs ne peuvent pas rattraper en quelques mois de panique post-incident. Cette régularité est ce qui sépare durablement les éditeurs sérieux des sites vulnérables qui dominent malheureusement encore le marché ouest-africain francophone.