Burp Scanner Pro pas-à-pas : crawl, audit actif/passif, lecture findings (2026)

📍 Article principal du cluster : Burp Suite : le guide pratique 2026
Cet article fait partie du cluster « Burp Suite 2026 ». Le Scanner est exclusif à Burp Pro — l’achat à 499 USD/an (cf. pilier) est requis. Pour la version manuelle libre, voir Repeater pas-à-pas.

Cadre éthique préalable. Le Scanner génère un trafic d’audit actif important. Lancé sur une cible non autorisée, c’est une intrusion caractérisée. Tous les scans décrits ici se font sur PortSwigger Academy, un lab personnel, ou dans le scope explicite d’une mission ou d’un programme bug bounty qui autorise les scanners. Lisez systématiquement les règles du programme — certains bug bounties interdisent le scanner automatique pour limiter le bruit.

Le Scanner est l’argument numéro un pour passer de Community à Pro. Ce moteur d’audit automatique parcourt une application, identifie les surfaces d’attaque, lance des payloads ciblés, et produit une liste structurée de findings classés par sévérité. Il sait détecter les classes principales de vulnérabilités web — SQL injection, XSS, SSRF, XXE, command injection, broken access control, problèmes TLS — avec un faible taux de faux positifs comparé aux concurrents enterprise. Ce tutoriel pas-à-pas couvre la configuration, le lancement, la lecture des findings, et le triage en mission réelle.

Prérequis

• Burp Suite Professional activé (Community n’a pas le Scanner).
• Un projet Burp sur disque (recommandé) — voir Installation et configuration.
• Une cible légale : lab PortSwigger, DVWA, OWASP Juice Shop, ou cible en scope mission.
• 16 Go de RAM minimum pour scans larges sans lenteur.
• Niveau : intermédiaire à avancé.
• Temps estimé : 60 minutes pour le tutoriel + temps de scan variable.

Étape 1 — Comprendre la division crawl + audit

Le Scanner opère en deux phases distinctes mais interconnectées. Crawl : Burp parcourt l’application comme le ferait un robot — il suit les liens, soumet des formulaires avec des valeurs neutres, identifie les endpoints, construit une cartographie. Audit : sur chaque endpoint identifié, Burp lance des payloads pour détecter les vulnérabilités.

Vous pouvez lancer les deux ensemble (mode classique « scan ») ou séparément. Sur un projet sérieux, beaucoup d’analystes préfèrent lancer un crawl d’abord, examiner la cartographie produite, exclure les zones sensibles (logout, suppression de compte), puis lancer l’audit ciblé sur le reste. Cette discipline évite les explosions de bruit et les actions destructives.

L’audit lui-même se subdivise en passif (Burp observe ce qui transite et marque les findings sans envoyer de payload — typiquement TLS faible, headers de sécurité manquants, cookies sans flag Secure) et actif (Burp injecte ses propres payloads pour tester SQL injection, XSS, etc.). Le passif est sans risque. L’actif demande l’autorisation explicite.

Étape 2 — Lancer un scan « depuis le proxy » sur ce que vous avez navigué

La méthode la plus naturelle : pendant que vous naviguez l’application via Firefox + Burp Proxy, lancez le scanner sur l’historique. Onglet Target → Site map. Vous voyez l’arborescence des URLs visitées. Clic droit sur le nœud racine de votre cible → Scan.

Une fenêtre s’ouvre avec deux onglets. Scan details : confirmez les URLs à scanner. Scan configuration : choisissez le type — « Audit only », « Crawl only », ou les deux. Pour ce premier exercice, prenez « Audit only » sur les URLs déjà visitées. Burp ne va pas crawler de nouvelles pages — il va auditer celles que vous avez déjà touchées manuellement.

Cliquez OK. L’onglet Dashboard de Burp affiche le scan en cours, sa progression, et les findings au fur et à mesure qu’ils sont identifiés. Une icône colorée indique la sévérité : rouge (High), orange (Medium), jaune (Low), gris (Information).

Étape 3 — Configurer un scan complet avec crawl

Pour un audit large, on lance crawl + audit en un seul scan. Onglet Dashboard → New scan. Choisissez « Crawl and Audit ». Entrez l’URL de départ — par exemple votre lab PortSwigger Academy.

Configurations clés à ajuster avant de lancer :

Application login. Si la cible nécessite authentification, vous fournissez ici les credentials. Burp se connectera automatiquement et maintiendra la session pendant le scan. Configurez aussi un « logout indicator » — une chaîne dans la réponse qui signale que la session est expirée — pour que Burp se reconnecte si la session tombe.

Crawl scope. Limitez le crawl au domaine de la cible. Excluez les sous-domaines tiers (CDN, analytics) qui ne font pas partie du périmètre. Excluez aussi les chemins destructifs : /logout, /admin/delete-user, /api/destroy.

Audit checks. Par défaut, tous les chèques actifs sont activés. Pour un premier scan, gardez la config par défaut. Pour des scans plus rapides ou plus discrets, désactivez les chèques très bruyants (XSS DOM-based, time-based blind injections).

Étape 4 — Surveiller le scan en cours

Pendant que le scan tourne, le Dashboard affiche en temps réel : pages crawlées, requêtes émises, issues détectées par sévérité. Vous pouvez naviguer dans Burp normalement — le scan tourne en tâche de fond.

Surveillez deux indicateurs critiques. Premier : la vitesse du crawl. Si Burp signale qu’il est ralenti par le serveur, c’est que le serveur applique du rate limiting ou que sa capacité plafonne. Le scan se prolonge. Pas de panique — laissez tourner. Deuxième : les erreurs réseau. Beaucoup de timeouts, beaucoup de 5xx — c’est que vous tapez trop fort. Pause le scan, baissez le débit dans Resource pool, reprenez.

Pour pauser ou arrêter : Dashboard → clic sur le scan → boutons « Pause » et « Cancel ». Pause permet de reprendre. Cancel termine définitivement.

Étape 5 — Lire et trier les findings

Une fois le scan progressé, basculez sur Target → Issues ou Dashboard → onglet Issues. Vous voyez la liste structurée. Chaque issue a : nom, sévérité, confiance (Certain, Firm, Tentative), URL affectée, description complète avec preuve, recommandation de remédiation.

Triage discipliné en quatre passes. Passe 1 : filtrer par sévérité High + confiance Certain. C’est ce qui doit aller dans le rapport en premier. Passe 2 : sévérité Medium + Firm. À vérifier manuellement avant de mettre dans le rapport, mais souvent valides. Passe 3 : Low. Souvent des optimisations de hardening (headers manquants), à mentionner en annexe. Passe 4 : Tentative. Faux positifs probables, à valider à la main avant inclusion.

Pour chaque finding important, ouvrez l’onglet « Advisory » : description détaillée, références (CWE, OWASP), exemples de PoC. L’onglet « Request » et « Response » montre exactement la requête qui a déclenché le finding et la preuve dans la réponse. C’est ce que vous mettez dans le rapport.

Étape 6 — Valider manuellement un finding avant rapport

Règle de pro : ne jamais inclure un finding du Scanner dans le rapport sans validation manuelle. Burp est bon mais pas infaillible. Pour chaque finding important, vous reproduisez à la main via Repeater.

Clic droit sur le finding → Send request to Repeater. Dans Repeater, vous avez la requête qui a déclenché. Renvoyez-la, observez la réponse. Si vous reproduisez le comportement rapporté par le Scanner, le finding est confirmé. Sinon, c’est un faux positif (la cible a peut-être évolué entre le scan et votre vérification, ou le Scanner s’est trompé).

Pour les vulnérabilités complexes (chained attacks, conditions de race, contextes spécifiques), la vérification manuelle est aussi l’occasion d’évaluer l’impact réel — un XSS sur une page non authentifiée est différent d’un XSS dans un panel admin. C’est cette évaluation contextuelle qui distingue un rapport bricolé d’un rapport pro.

Étape 7 — Configurer Burp Collaborator pour les attaques out-of-band

Certaines vulnérabilités ne se voient pas dans la réponse directe — typiquement les blind SSRF, blind SQL injection, blind XXE. Le Scanner les détecte via Burp Collaborator : un service hébergé par PortSwigger qui vous donne un domaine unique *.burpcollaborator.net. Burp injecte ce domaine dans des payloads ; si la cible le déréférence, vous voyez la connexion entrante côté Collaborator.

Vérifiez que Collaborator est actif : Burp menu → Settings → Project → Collaborator server. Le domaine par défaut est celui de PortSwigger. Pour les missions avec contraintes (réseau enterprise qui bloque les domaines externes), vous pouvez auto-héberger un Collaborator privé — documentation officielle PortSwigger.

Quand le Scanner identifie un blind SSRF, le finding apparaît avec « Out-of-band » dans le titre, et la preuve inclut la requête entrante observée par Collaborator. C’est le genre de finding qui vaut beaucoup en bug bounty.

Étape 8 — Étendre le Scanner avec Active Scan++

L’extension Active Scan++ du BApp Store ajoute des chèques que le Scanner officiel ne fait pas — notamment HTTP Request Smuggling avancé, Server-Side Template Injection (SSTI), Cache Poisoning, et plusieurs variantes d’injection. Installation : Extensions → BApp Store → search « Active Scan++ » → Install.

Une fois installée, l’extension s’intègre nativement au Scanner. Lors du prochain scan, les nouveaux chèques s’exécutent automatiquement. Pas de configuration supplémentaire nécessaire.

D’autres extensions enrichissent le Scanner : Backslash Powered Scanner de PortSwigger Research pour les injections novatrices, J2EE Scan pour des chèques spécifiques aux applications Java EE, Software Vulnerability Scanner pour identifier les versions de bibliothèques vulnérables détectées dans les réponses. Le tutoriel Extensions BApp essentielles couvre les choix recommandés.

Étape 9 — Exporter les findings pour le rapport

Une fois le triage terminé, exportez les findings retenus pour intégration dans votre rapport. Target → Issues, sélectionnez les issues à exporter (Ctrl+clic pour plusieurs), clic droit → Report issues.

L’assistant propose plusieurs formats : HTML (lisible directement, recommandé pour partager au client), XML (pour intégration dans des outils tiers), et un format custom via template. Choisissez les options de contenu : description, requête, réponse, remediation. Pour un rapport client, gardez tout. Pour un rapport interne, vous pouvez réduire.

Le HTML produit est mis en page proprement, avec sommaire navigable, tableau des findings par sévérité, et détails techniques. Vous pouvez le joindre tel quel à votre livrable, ou en extraire les sections pour les coller dans un rapport plus large rédigé en Word ou en LaTeX.

Étape 10 — Vérifier votre maîtrise par un audit complet

Pour valider, lancez un scan complet sur OWASP Juice Shop installé en local (Docker : docker run -p 3000:3000 bkimminich/juice-shop). Configuration : crawl + audit, login avec un compte test, scope strict sur le domaine local.

Laissez tourner 30 à 60 minutes. À la fin, vous devriez avoir une liste d’une vingtaine de findings au moins, couvrant XSS, broken access control, exposed information, faiblesses crypto. Triez, validez deux ou trois findings High manuellement, exportez en HTML.

Si vous arrivez à présenter un rapport propre avec dix findings vérifiés et leur reproduction manuelle, le Scanner est sous votre maîtrise. Vous êtes prêt pour les missions réelles.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour un audit sur une plateforme e-commerce hébergée chez un prestataire africain (Africa Data Centers, Sonatel Cloud, hébergeurs locaux), prévenez systématiquement l’équipe d’hébergement avant de lancer un scan complet. Beaucoup ont des pares-feu applicatifs qui bloquent les patterns Burp connus, et votre IP source peut être blackliste sans préavis. Une coordination simple par email ou WhatsApp avec l’admin technique du client résout 90 % des problèmes.

Pour les apps avec intégrations paiement mobile (CinetPay, Wave, Orange Money), excluez explicitement les endpoints de transaction du scan automatique. Le Scanner peut générer des transactions test qui échouent mais qui restent dans les logs financiers — bruit à éviter pour le client. Auditez ces endpoints manuellement avec Repeater.

Pour les rapports clients en français, exportez le HTML Burp puis traduisez les sections critiques en français — Burp produit en anglais nativement. Les CWE et références techniques restent en anglais (standard international), mais les explications de remédiation gagnent à être en français pour le décideur local. Beaucoup de rapports pro francophones gardent un mix : technique en anglais, exécutif en français.

Tutoriels frères

• Repeater pas-à-pas — pour valider manuellement les findings.
• Extensions BApp essentielles — Active Scan++, Backslash Powered Scanner, etc.
• Workflow bug bounty — où le Scanner s’intègre dans le flux complet.

Pour aller plus loin

• 🔝 Retour au pilier : Burp Suite : le guide pratique 2026
• Documentation Scanner : portswigger.net/burp/documentation Scanning
• Burp Collaborator : portswigger.net/burp/documentation Collaborator
• Suggestion : enchaînez avec JWT et OAuth pour les classes d’attaques que le Scanner couvre partiellement.

FAQ

Le Scanner Burp est-il aussi bon qu’Acunetix ou Invicti ?
Sur la qualité de détection, oui — comparable voire supérieur sur plusieurs classes (broken access control, XSS DOM-based, attaques out-of-band). Sur l’industrialisation pure (déploiement multi-cibles, rapports automatiques), Burp Pro est inférieur ; c’est ce que Burp Enterprise compense.

Combien de temps prend un scan complet ?
Variable. Sur une petite app de 50 pages, comptez 30 minutes. Sur une grosse app de 1000 pages avec auth, comptez 6 à 12 heures. Lancez en heures creuses pour limiter l’impact sur l’utilisateur final.

Le Scanner casse-t-il les applications fragiles ?
Possible. Sur des apps avec données critiques ou chemins destructifs, les payloads actifs peuvent provoquer des effets de bord. Toujours scanner sur staging d’abord, en prod uniquement avec accord et fenêtre dédiée.

Comment intégrer Burp Scanner à un pipeline CI ?
Pas natif sur Pro desktop. Pour CI/CD, c’est Burp Suite Enterprise Edition qui expose une API REST scriptable. Pour un usage Pro, vous pouvez automatiser via le module REST API local de Burp + scripts maison, mais c’est artisanal.

Le Scanner accepte-t-il les apps SPA / GraphQL ?
Oui pour les SPA (le crawler comprend le JavaScript moderne depuis 2022). Pour GraphQL, l’extension InQL (BApp Store) ajoute le support introspection et fuzzing des résolveurs.

Mots-clés secondaires : Burp Scanner Pro, DAST, audit actif passif, Burp Collaborator, Active Scan++, findings triage, rapport pentest.