WARN-NEW: X-Content-Type-Options Header Missing : ce type d’alerte, générée par un scan dynamique, ne remonte jamais d’une analyse de code statique, puisqu’elle concerne un en-tête HTTP envoyé au moment de la requête réelle, pas une ligne de code isolée. C’est précisément ce que couvre un outil comme Semgrep ou SonarQube, qui ne sera pas traité ici, et ce que couvre ZAP en scannant une application réellement en fonctionnement.
OWASP ZAP (Zed Attack Proxy) propose un mode « baseline », plus léger que son scan actif complet, pensé pour s’intégrer à un pipeline sans nécessiter d’autorisation spéciale ni risquer d’endommager l’environnement testé. Ce billet montre comment l’ajouter avant chaque déploiement, contre un environnement de recette dédié.
Ce que le mode baseline fait, et ne fait pas
Le scan baseline se contente d’observer passivement le trafic généré en naviguant automatiquement sur le site pendant une durée limitée, sans jamais tenter d’exploiter activement une faille détectée. Il détecte des configurations manquantes ou risquées : en-têtes de sécurité absents, cookies sans attribut Secure, informations de version exposées dans les réponses.
docker run -t owasp/zap2docker-stable zap-baseline.py \
-t https://recette.exemple-projet.test \
-r rapport-zap.html \
-I
L’option -I demande à ZAP de ne pas retourner de code de sortie d’échec même en présence d’alertes, ce qui permet dans un premier temps d’observer les résultats sans bloquer immédiatement le pipeline pendant la phase de calibrage.
Cibler un environnement de recette dédié, jamais la production
Le scan génère un trafic automatisé conséquent, avec de nombreuses requêtes en peu de temps. Il doit systématiquement cibler un environnement de recette isolé, jamais la production, pour éviter tout impact sur de vrais visiteurs ou une charge inattendue sur l’infrastructure réelle :
- Déployer la version candidate sur un environnement de recette accessible depuis le pipeline.
- Lancer le scan ZAP contre cette URL de recette, une fois le déploiement de recette confirmé fonctionnel.
- Archiver le rapport HTML généré comme artefact du pipeline, consultable même après suppression de l’environnement.
Filtrer les faux positifs sans désactiver tout le scan
Une première exécution génère souvent des alertes déjà connues et jugées non pertinentes pour le contexte du projet, par exemple un en-tête absent volontairement à ce stade ou une alerte liée à une bibliothèque tierce déjà auditée par ailleurs. ZAP accepte un fichier de règles qui ignore ces alertes spécifiques sans désactiver la détection globale :
# regles-zap.tsv
10038 IGNORE (Content Security Policy Header Not Set)
10063 IGNORE (Permissions Policy Header Not Set)
zap-baseline.py -t https://recette.exemple-projet.test \
-c regles-zap.tsv -r rapport-zap.html
Ce fichier doit rester revu régulièrement : une alerte ignorée aujourd’hui pour une bonne raison peut redevenir pertinente après un changement de configuration serveur, et mérite d’être réévaluée périodiquement plutôt que d’être oubliée définitivement.
Passer du mode observation au mode bloquant
Une fois les faux positifs filtrés et le rapport stabilisé sur plusieurs exécutions, retirer l’option -I permet au scan de faire échouer le pipeline en cas de nouvelle alerte non filtrée, ce qui transforme l’outil d’un simple rapport consultatif en une véritable porte de qualité avant chaque mise en production.
- Commencer en mode observation pendant plusieurs cycles avant d’activer le blocage.
- Impliquer l’équipe dans la revue des premières alertes, pour éviter un rejet du processus perçu comme arbitraire.
- Documenter chaque exclusion ajoutée au fichier de règles, avec la raison qui la justifie.
Un scan de sécurité qui bloque dès sa première exécution, sans phase d’observation préalable, se fait généralement désactiver par l’équipe avant même d’avoir prouvé sa valeur.
En résumé
Le mode baseline de ZAP ajoute une couche de vérification que l’analyse statique ne peut pas fournir, en observant le comportement réel d’un environnement de recette déployé. Une phase d’observation, suivie d’un filtrage soigné des faux positifs, permet d’installer ce scan comme porte de qualité sans provoquer un rejet immédiat de la part de l’équipe.
