Maîtriser OWASP ZAP

OWASP ZAP (Zed Attack Proxy) est un proxy d'interception et un scanner de vulnérabilités web développé par l'OWASP. Il est entièrement gratuit, open source (licence Apache 2.0) et maintenu par une communauté internationale.

ZAP s'utilise à toutes les étapes d'un test d'intrusion : exploration (spidering), interception manuelle, scan automatique, fuzzing, exploitation et reporting. Il s'intègre nativement dans les pipelines DevSecOps via Docker, GitHub Actions et son framework d'automatisation YAML.

Pourquoi l'utiliser ? Parce que le scan actif est inclus gratuitement, que l'API REST est complète, et que le mode headless permet de l'automatiser sans interface graphique.

ZAP est une application Java. Java 11 minimum est requis (Java 17 recommandé pour les dernières versions). Il existe plusieurs formats d'installation selon votre système.

• macOS : brew install --cask zap ou téléchargement du .dmg sur zaproxy.org.
• Windows : installeur .exe officiel, inclut le runtime Java.
• Linux générique : archive .tar.gz sur le site officiel, puis ./zap.sh.

Pour intercepter le trafic avec ZAP, il faut faire passer Firefox par le proxy de ZAP, puis installer le certificat racine de ZAP pour déchiffrer le HTTPS. C'est une étape obligatoire pour tester des applications modernes.

Au lancement, ZAP écoute par défaut sur localhost:8080. Vérifiez dans Tools → Options → Network → Local Servers/Proxies. Notez l'adresse et le port (par exemple 127.0.0.1:8080).

1. Ouvrir Paramètres → Général → Paramètres réseau.
2. Choisir Configuration manuelle du proxy.
3. Renseigner : HTTP Proxy : 127.0.0.1, Port : 8080.
4. Cocher Utiliser ce proxy pour tous les protocoles.
5. Valider.

1. Dans Firefox, aller sur http://zap/ ou http://localhost:8080.
2. Télécharger le certificat OWASP ZAP Root CA (owasp_zap_root_ca.cer).
3. Dans Firefox : Paramètres → Vie privée et sécurité → Afficher les certificats → Autorités.
4. Cliquer sur Importer, sélectionner le fichier .cer.
5. Cocher Confirmer cette autorité pour identifier des sites web.

Pour activer/désactiver le proxy en un clic, installez l'extension FoxyProxy dans Firefox. Créez un profil : type HTTP, hôte 127.0.0.1, port 8080. Vous pourrez basculer entre navigation normale et navigation via ZAP.

ZAP propose plusieurs modes pour s'adapter au contexte du test. Comprendre ces modes évite d'envoyer du scan actif par erreur sur une cible de production.

Le spider explore le site pour cartographier toutes les URLs accessibles. ZAP dispose de deux moteurs complémentaires.

1. Clic droit sur une URL dans l'onglet Sites.
2. Attack → Spider…
3. Renseigner éventuellement un contexte, un utilisateur, un point de départ.
4. Cliquer sur Start Scan.

C'est la distinction fondamentale à comprendre avant d'utiliser ZAP. Les deux types de scan coexistent et se complètent.

Le scan passif tourne en permanence dès que vous naviguez via le proxy. Chaque réponse HTTP est analysée par une série de règles passives. Pour consulter les résultats : onglet Alerts, filtre Passive.

Exemples d'alertes passives :

• X-Content-Type-Options manquant → risque de MIME sniffing
• Cookie sans attribut Secure ou HttpOnly
• En-tête Content-Security-Policy absent ou trop permissif
• Version de serveur exposée (Server: Apache/2.4.29)
• Cookie de session sans attribut SameSite

Le scan actif envoie des payloads d'attaque dans chaque paramètre découvert. Il faut définir précisément la cible.

1. Clic droit sur l'URL cible dans Sites.
2. Attack → Active Scan…
3. Choisir un contexte, une politique (Default Policy), un utilisateur si authentifié.
4. Ajuster l'intensité (LOW/MEDIUM/HIGH/INSANE) et le seuil (LOW/MEDIUM/HIGH).
5. Start Scan.

L'onglet Active Scan montre en temps réel la règle en cours, le nombre de requêtes envoyées, et le nombre d'alertes produites.

Le Cross-Site Scripting est une injection de code JavaScript côté client. On distingue trois variantes, chacune couverte par une ou plusieurs règles ZAP.

URL vulnérable typique :

ZAP envoie plusieurs variantes (balise script, attribut d'événement, URL javascript:, SVG, etc.) pour couvrir tous les contextes d'injection.

Le XSS DOM-based ne passe pas par le serveur : le JavaScript de la page lit une valeur (URL, fragment, localStorage) et l'injecte dans le DOM via un sink dangereux.

ZAP utilise l'add-on DOM XSS Active Scan Rule qui lance un navigateur headless pour exécuter le JS et observer le comportement.

Sinks surveillés :

• innerHTML, outerHTML
• document.write, document.writeln
• eval, setTimeout, setInterval
• element.src, element.href

L'injection SQL permet de manipuler les requêtes envoyées à la base de données. ZAP dispose de plusieurs règles, adaptées aux SGBD courants.

Sur le challenge SQL Injection (advanced) de WebGoat, ZAP a détecté la faille via la règle Hypersonic SQL dans le paramètre column de l'endpoint /WebGoat/attack.

Le payload injecté était du type : ' OR '1'='1' --, provoquant une réponse différente (taille, contenu) qui a déclenché l'alerte.

L'IDOR (Insecure Direct Object Reference) survient lorsqu'une ressource est accessible en manipulant un identifiant (ID utilisateur, ID de commande, ID de fichier) sans contrôle d'accès. ZAP ne dispose pas d'une règle active dédiée, mais propose plusieurs fonctionnalités pour la tester.

La règle passive Username IDOR analyse les réponses pour identifier des paramètres contenant des identifiants (IDs numériques, UUID, tokens). Elle produit une alerte Information qui invite à un test manuel.

L'add-on Replacer (Ctrl + R) permet de substituer des chaînes dans les requêtes/réponses automatiquement. C'est l'outil idéal pour tester un IDOR sur un token de session.

1. Intercepter une requête contenant un identifiant (cookie, header, paramètre).
2. Créer une règle : Match String = token utilisateur A, Replacement String = token utilisateur B.
3. Envoyer la requête via le Manual Request Editor.
4. Analyser la réponse : si l'utilisateur B accède aux données de A, l'IDOR est confirmé.

Pour un paramètre user_id=1, utilisez le Fuzzer avec le payload Numberzz pour itérer de 1 à N. Triez les réponses par taille de corps : les valeurs qui renvoient des données différentes sont des ressources accessibles.

Pour aller plus loin, écrivez un script qui marque automatiquement les réponses intéressantes :

Ce script marque les réponses contenant le mot "super", ce qui révèle rapidement les comptes privilégiés (ex. ID 42 d'un super-admin).

L'injection CSS est moins couverte par les règles automatiques de ZAP. Elle est détectée principalement via l'analyse des en-têtes CSP et des tests manuels.

Pour tester les zones authentifiées (et détecter les IDOR, les élévations de privilèges, les fuites de données), ZAP doit pouvoir se connecter comme un utilisateur légitime.

1. Menu File → New Context (ou clic droit sur une URL → Include in Context).
2. Dans l'onglet Contexts, définir le périmètre (URLs incluses/exclues).
3. Onglet Authentication : choisir une méthode (Form-based, JSON-based, Script-based).
4. Onglet Users : créer un utilisateur avec login/mot de passe.
5. Onglet Session Management : configurer la gestion des cookies/tokens.
6. Cliquer sur Forced User Mode pour que ZAP utilise toujours cet utilisateur.

Après configuration, utilisez le bouton Check Logged In/Out dans l'onglet Authentication. ZAP envoie une requête et vérifie si la réponse correspond à un état connecté ou déconnecté.

Le fuzzer de ZAP permet d'injecter des payloads dans n'importe quelle partie d'une requête : paramètres, en-têtes, cookies, corps. C'est l'outil polyvalent pour l'exploration de failles non couvertes par les règles actives.

1. Dans l'onglet History, clic droit sur une requête.
2. Attack → Fuzz…
3. Sélectionner la ou les positions à fuzzer (bouton Add).
4. Choisir un ou plusieurs payloads (Fichiers, Numberzz, Regex, scripts).
5. Cliquer sur Start Fuzzer.

Les Fuzzer HTTP Processors sont des scripts qui analysent les réponses en temps réel pendant le fuzz. Utile pour détecter des motifs spécifiques sans tout relire manuellement.

Après un fuzz, triez les résultats par taille de réponse, code HTTP ou état personnalisé. Les réponses anormalement grandes ou petites révèlent souvent des comportements intéressants (fuite de données, bypass d'authentification).

Voici un scénario d'attaque complet, de bout en bout, utilisant Firefox comme navigateur et ZAP comme proxy/outil d'exploitation. Cible d'exemple : DVWA (Damn Vulnerable Web Application), en local.

1. Naviguer vers http://localhost/.
2. Login : admin / password.
3. Aller dans DVWA Security et mettre le niveau sur Low.
4. Ouvrir ZAP, constater que les requêtes sont interceptées.

Clic droit sur http://localhost/ dans ZAP → Attack → Spider… → Start. Puis relancer avec Ajax Spider pour couvrir le JS.

Clic droit sur http://localhost/vulnerabilities/xss_r/ → Attack → Active Scan… Lancer avec la politique par défaut. L'alerte Cross Site Scripting (Reflected) doit apparaître.

Dans Firefox, naviguer vers :

Une popup s'affiche avec le cookie de session. C'est la preuve du XSS.

Pour exploiter plus loin, remplacer alert par une requête vers un serveur attaquant :

1. Activer le mode Break dans ZAP.
2. Dans Firefox, soumettre le formulaire XSS.
3. ZAP intercepte la requête : modifier le payload en direct.
4. Cliquer sur Submit pour l'envoyer.
5. Analyser la réponse.

ZAP dispose d'un HUD (Heads Up Display) qui s'affiche directement dans Firefox. Activer dans ZAP : Tools → Options → HUD → Enable. Recharger la page dans Firefox.

Depuis le HUD, vous pouvez :

• Lancer un scan actif sur la page courante
• Voir les alertes sans quitter Firefox
• Injecter un payload directement dans un formulaire

1. Identifier une requête contenant un ID de ressource (ex. /api/user/1/profile).
2. Créer une règle Replacer : Match = /user/1/, Replacement = /user/2/.
3. Envoyer la requête via Manual Request Editor.
4. Observer si les données de l'utilisateur 2 sont accessibles.

Sur l'endpoint http://localhost/vulnerabilities/sqli/?id=1&Submit=Submit, clic droit dans History → Attack → Fuzz…. Sélectionner la valeur 1 du paramètre id. Ajouter un payload File avec la liste SQLi de SecLists.

Analyser les résultats : les réponses contenant des erreurs SQL (You have an error in your SQL syntax) confirment la faille.

Menu Report → Generate HTML Report. Sélectionner le contexte ou toutes les alertes. Le rapport inclut chaque faille, sa sévérité, sa description, la requête/réponse associée et les recommandations de remédiation.

C'est le point fort de ZAP par rapport aux outils commerciaux. Le Automation Framework permet de décrire un plan de scan complet dans un fichier YAML, reproductible et versionné.

ZAP expose une API REST complète (JSON) permettant de le piloter à distance, depuis n'importe quel langage. Utile pour scripter des scénarios complexes ou intégrer ZAP à un orchestrateur.

Par défaut, l'API ZAP est protégée par une clé. La récupérer dans Tools → Options → API ou en variable d'environnement (ZAP_API_KEY).

ZAP génère des rapports détaillés dans plusieurs formats : HTML, JSON, XML, Markdown. Chaque alerte est classée par sévérité et degré de confiance.

Pour la CI, définissez un fichier zap-rules.conf qui fixe le comportement de chaque règle :

Les niveaux possibles sont IGNORE, INFO, WARN, FAIL. Avec FAIL, le pipeline CI échoue si la règle est déclenchée.

Chaque alerte ZAP est associée à des tags (ex : OWASP_2021_A03 pour l'injection). Dans le fichier .conf, vous pouvez cibler des groupes entiers :

• Failles de logique métier : non couvertes par les règles automatiques, à tester manuellement.
• IDOR : détection partielle, nécessite une configuration d'authentification et un test manuel.
• Faux positifs XSS : ZAP peut signaler des XSS sur des contextes non exploitables (ex. JSON échappé).
• XSS stocké : la détection par re-crawl peut échouer si l'application nettoie les jetons.
• Authentification complexe : OAuth2/SAML multi-étapes nécessite un script personnalisé.
• Scan actif destructeur : certains payloads peuvent modifier/supprimer des données. Toujours tester sur une copie.

1. Phase 1 — Reconnaissance manuelle avec Firefox + ZAP en proxy : comprendre l'application, ses flux, ses formulaires.
2. Phase 2 — Spider (traditionnel + AJAX) pour cartographier.
3. Phase 3 — Scan passif : récolter les premières alertes (headers, cookies, CSP).
4. Phase 4 — Scan actif ciblé sur les endpoints sensibles (login, recherche, upload, API).
5. Phase 5 — Tests manuels (IDOR, logique métier, XSS stocké) aidés par le Replacer et le Fuzzer.
6. Phase 6 — Rédaction du rapport et priorisation des correctifs.

Ce tutoriel couvre l'essentiel de ZAP. Pour approfondir, explorez les add-ons du Marketplace, écrivez vos propres scripts d'authentification, et testez ZAP sur les challenges de l'OWASP (WebGoat, Juice Shop, DVWA).

Voir la Formation 2026 → Tous les tutoriels →