OWASP ZAP expliqué : ce qu’il scanne et les 10 alertes les plus courantes

OWASP ZAP est un scanner gratuit et open source qui regarde un site comme le ferait le premier outil d’un attaquant. Il parcourt le site, lit chaque réponse et signale ce qui paraît anormal : un en-tête de sécurité absent, un cookie sans drapeau, un formulaire sans jeton. C’est une explication de l’outil ; ce qu’ont montré les propres scans baseline de Kasandro est dans l’article sur nos contrôles.

OWASP ZAP en un paragraphe

ZAP (Zed Attack Proxy) est décrit par le site du projet comme gratuit et open source, « le scanner d’applications web le plus utilisé au monde ». Il se place comme proxy entre le navigateur et le site, ou explore le site seul, et lève des alertes, chacune avec un identifiant et un nom du catalogue public. Son site porte la marque « ZAP by Checkmarx » et appelle aussi ZAP un projet open source indépendant. On le lance depuis une application de bureau, depuis Docker ou comme étape de CI.

Scan baseline et scan actif

Le scan baseline est le léger. D’après sa documentation, il lance le spider une minute par défaut, attend la fin du scan passif et rend compte. Il ne fait « aucune véritable attaque » : il lit seulement les réponses que le site renvoie de toute façon, donc il est sûr sur votre propre site, dure quelques minutes et tient dans une chaîne de CI. Par défaut chaque alerte est un avertissement ; un fichier de règles peut transformer une règle en IGNORE, INFO ou FAIL.

Un scan actif envoie des requêtes proches d’attaques (par exemple des charges d’injection SQL ou de XSS réfléchi). Il peut modifier des données ; sa place est donc sur une copie de test, et seulement sur un système que vous avez le droit de tester.

Les 10 alertes les plus courantes

Ces dix alertes sont celles que les sites ordinaires reçoivent le plus souvent d’un scan baseline. Les ID et noms viennent du catalogue de ZAP.

1. Content Security Policy (CSP) Header Not Set (10038). Le site ne dit pas au navigateur quels scripts et images il peut charger, ce qui facilite la vie d’un script injecté. Correction : un en-tête Content-Security-Policy avec les sources réellement utilisées.
2. Missing Anti-clickjacking Header (10020). Un autre site peut intégrer le vôtre dans un cadre caché et glisser un clic. Correction : frame-ancestors dans la CSP ou X-Frame-Options.
3. X-Content-Type-Options Header Missing (10021). Le navigateur peut deviner le type d’un fichier et exécuter ce qui devait être du texte. Correction : X-Content-Type-Options: nosniff.
4. Strict-Transport-Security Header Not Set (10035). Une première visite en HTTP simple peut être interceptée. Correction : Strict-Transport-Security dans les réponses HTTPS.
5. Cookie No HttpOnly Flag (10010). Un script de la page peut lire le cookie. Correction : HttpOnly sur les cookies de session.
6. Cookie without SameSite Attribute (10054). Le cookie voyage avec les requêtes venant d’autres sites. Correction : SameSite à Lax ou Strict quand le parcours le permet.
7. Server Leaks Version Information via "Server" HTTP Response Header Field (10036). La version exacte du logiciel aide à choisir un exploit connu. Correction : ne pas envoyer la version.
8. Cross-Domain Misconfiguration (10098). Le site autorise d’autres origines à lire ses réponses plus largement que nécessaire. Correction : nommer les origines de confiance plutôt qu’un joker.
9. Absence of Anti-CSRF Tokens (10202). Un autre site peut soumettre un formulaire au nom d’un utilisateur connecté. Correction : un jeton par formulaire, ou une politique de cookies stricte avec vérification de l’origine.
10. Vulnerable JS Library (10003). Une bibliothèque embarquée a une faille connue. Correction : la mettre à jour ; un audit des dépendances en CI la détecte plus tôt.

Deux autres se rencontrent en scan actif : SQL Injection (40018) et Cross Site Scripting (Reflected) (40012).

Ce qu’un scan propre ne prouve pas

Un scan baseline lit des réponses : il ne se connecte pas, ne comprend pas votre logique d’argent et ne cherche pas une règle d’accès cassée entre deux utilisateurs. Un résultat propre veut dire « aucune erreur connue d’en-tête ou de cookie sur les pages atteintes par le spider ». C’est un plancher, pas un certificat, et cela ne remplace ni une revue du code ni un test d’intrusion par une personne.

Où en est le groupe veinito

ClassKasa, produit frère du groupe veinito, a un job de scan OWASP ZAP baseline dans sa chaîne de CI, et depuis le 13 octobre 2026 Kasandro exécute le même scan baseline à chaque changement de code : les nouveaux résultats arrêtent le build. Le premier passage, 63 contrôles réussis et 0 échoué, est décrit dans notre article sur les contrôles.

FAQ

OWASP ZAP est-il gratuit ?

Oui. Le site du projet le décrit comme gratuit et open source.

Un scan baseline ZAP est-il sûr sur mon propre site ?

La documentation dit que le scan baseline ne réalise pas d’attaques ; il explore le site et analyse passivement les réponses. Lancez-le sur des systèmes qui vous appartiennent ou que vous avez le droit de tester.

Un scan ZAP propre signifie-t-il qu’un site est sûr ?

Non. Cela signifie que ZAP n’a trouvé aucun problème connu d’en-tête, de cookie ou de bibliothèque sur les pages atteintes. Les erreurs de logique et d’accès demandent une relecture par une personne.

Kasandro a-t-il été scanné avec ZAP ?

Oui : le scan baseline tourne à chaque changement de code depuis le 13 octobre 2026, et les nouveaux résultats arrêtent le build. Le premier passage est décrit dans notre article sur les contrôles.