Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Active Scan

devsecops

Définition

Un Active Scan (scan actif) est une technique de test de sécurité dynamique (DAST) qui envoie activement des requêtes HTTP contenant des payloads de test vers une application web pour détecter et confirmer des vulnérabilités exploitables. Contrairement au Passive Scan qui observe passivement le trafic existant, le scan actif probe agressivement l'application avec des inputs malveillants (injections SQL, XSS payloads, commandes shell) pour vérifier si l'application est vulnérable. Le scan actif est le cœur du DAST traditionnel : des outils comme OWASP ZAP, Burp Suite Professional, et des scanners spécialisés (w3af, Nikto, Arachni) envoient des milliers de requêtes modifiées vers chaque point d'entrée découvert (paramètres URL, corps de formulaires, cookies, headers) pour détecter des vulnérabilités d'injection (SQL, XSS, XXE, SSTI, command injection), des problèmes de contrôle d'accès (IDOR, bypass d'authentification), et des misconfigurations de sécurité. Le scan actif est intrinsèquement perturbateur : il crée des entrées dans les bases de données, peut déclencher des alertes de sécurité, modifier des données, et dans les cas extrêmes provoquer des indisponibilités sur des applications fragiles. Pour cette raison, le scan actif est réservé aux environnements de test (staging) et ne doit jamais être exécuté sur la production sans coordination préalable et autorisations explicites. La configuration d'un scan actif efficace nécessite une définition précise du scope (URLs à inclure et exclure), des credentials d'authentification pour tester les fonctionnalités protégées, des politiques de scan adaptées à la technologie (profils SQL pour les backends SQL, profils NoSQL pour MongoDB/Redis), et des mécanismes pour éviter des actions destructives irréversibles (exclusion des endpoints de suppression de données ou de déconnexion des sessions de scan). Les résultats du scan actif doivent être triés par sévérité et validés manuellement pour éliminer les faux positifs : les scanners automatiques génèrent des faux positifs sur certains types de vulnérabilités (XSS dans les contextes avec CSP strict, injections SQL dans les ORMs avec prepare statements).

Configuration d'un scan actif OWASP ZAP

Configuration recommandée pour un scan actif ZAP dans un pipeline CI : zap-full-scan.py -t https://staging.example.com -j (format JSON) -r zap-report.html -I (ne pas bloquer sur les alertes info) -a (inclure le scan actif) avec les options --auth-form-url, --auth-username, --auth-password pour l'authentification. La configuration d'un fichier de context ZAP (scope, exclusions, authentification) permet de réutiliser la même configuration entre les runs et d'exclure les endpoints dangereux (logout, delete all data).

Triage et validation des résultats de scan actif

Les résultats d'un scan actif nécessitent un triage rigoureux : 1) Alertes High/Critical — validation manuelle obligatoire (reproduction de la vulnérabilité pour confirmer l'exploitabilité). 2) Alertes Medium — revue prioritaire, peuvent être des faux positifs fréquents (XSS réfléchi détecté dans des contextes où l'output est échappé). 3) Alertes Low/Informational — traitement en backlog. Un processus de "known false positives" configuré dans ZAP (via des rules de suppression) évite de retrier les mêmes faux positifs à chaque scan.

Scan actif authentifié vs non-authentifié

La couverture d'un scan actif non-authentifié est limitée aux fonctionnalités publiques (formulaire de login, pages publiques) — insuffisant pour tester la plupart des vulnérabilités de l'application qui nécessitent une authentification. Un scan actif authentifié nécessite : la configuration de credentials de test (compte dédié au scan avec des données de test, pas un compte de production), la configuration du mécanisme d'authentification (form-based, Bearer token, session cookie), et la gestion de la réauthentification automatique quand la session expire pendant le scan. ZAP et Burp Suite Professional supportent ces configurations avancées d'authentification.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis