Burp Suite Proxy : intercepter sa première requête + certificat CA (2026)

📍 Article principal du cluster : Burp Suite : le guide pratique 2026
Cet article fait partie du cluster « Burp Suite 2026 ». Pour l’installation préalable, voir Installer et configurer Burp Suite.

Cadre éthique préalable. Tout intercept doit cibler une application que vous avez le droit de tester : votre propre app en dev, un lab personnel (DVWA, OWASP Juice Shop, PortSwigger Academy), ou une cible en bug bounty officiel. Intercepter le trafic d’un tiers sans autorisation est une infraction pénale dans tous les pays d’Afrique de l’Ouest. Ce tutoriel suppose ce cadre acquis.

Le Proxy est le cœur de Burp. Sans intercept, pas de Repeater, pas d’Intruder, pas de Scanner. Toutes les autres fonctionnalités s’appuient sur cette première étape : capter une requête entre votre navigateur et le serveur cible. Le piège des débutants, c’est l’HTTPS — sans installation préalable du certificat CA de Burp dans le navigateur, chaque page produit un avertissement de sécurité, et votre flux est cassé. Ce tutoriel règle le problème en quinze minutes.

Prérequis

• Burp Suite installé (Community ou Pro). Voir Installation Burp Suite.
• Un navigateur sur la même machine : Firefox de préférence (gestion indépendante du store de certificats), ou Chrome/Edge.
• Une application cible autorisée. Pour le tutoriel, on utilise PortSwigger Web Security Academy qui héberge des labs prévus pour ça.
• Niveau : débutant. Aucune compétence préalable.
• Temps estimé : 30 minutes.

Étape 1 — Lancer Burp et identifier le port du Proxy

Lancez Burp Suite. Au choix de projet, prenez « Temporary project » pour ce tutoriel. Une fois l’interface ouverte, allez sur l’onglet Proxy → Proxy settings. Vous voyez la section « Proxy listeners ». Par défaut, Burp écoute sur 127.0.0.1:8080 — c’est l’adresse à laquelle votre navigateur va devoir envoyer son trafic.

Vous pouvez modifier le port si 8080 est déjà occupé sur votre machine. Pour la suite du tutoriel, on suppose 8080. Vérifiez que le listener est en statut « Running » — case « Running » cochée. Si elle est décochée pour une raison ou une autre, recochez-la.

Étape 2 — Configurer Firefox pour passer par Burp

Firefox a son propre store de certificats indépendant du système, ce qui est plus propre que Chrome. Ouvrez Firefox. Allez dans Paramètres → Général → Paramètres réseau → Paramètres. Cochez « Configuration manuelle du proxy » et entrez :

Proxy HTTP : 127.0.0.1
Port : 8080
[x] Aussi utiliser ce proxy pour HTTPS

Validez. Désormais tout le trafic HTTP et HTTPS de Firefox passe par Burp. À ce stade, si vous tentez d’aller sur un site HTTPS, vous recevrez un avertissement « Connexion non sécurisée » — c’est attendu, parce que Burp intercepte le TLS avec son propre certificat que Firefox ne connaît pas encore. C’est l’étape suivante qui règle ça.

Étape 3 — Télécharger le certificat CA de Burp

Avec Firefox configuré sur le proxy, ouvrez l’URL spéciale http://burp (en HTTP, pas HTTPS) dans Firefox. Une page d’accueil de Burp Suite s’affiche. En haut à droite, cliquez sur « CA Certificate ». Un fichier cacert.der se télécharge.

Ce fichier est l’autorité de certification (CA) que Burp utilise pour signer les certificats qu’il génère à la volée pour chaque site HTTPS que vous visitez. En l’ajoutant comme autorité de confiance dans Firefox, vous dites à Firefox « accepte les certificats signés par cette CA », et l’avertissement disparaît.

Étape 4 — Importer le certificat dans Firefox

Toujours dans Firefox, allez dans Paramètres → Vie privée et sécurité → Certificats → Afficher les certificats → Autorités. Cliquez sur « Importer ». Sélectionnez le fichier cacert.der téléchargé. Une fenêtre demande quelles utilisations autoriser pour cette CA. Cochez :

[x] Confirmer cette CA pour identifier des sites web

Validez. Le certificat « PortSwigger CA » apparaît désormais dans la liste des autorités. Fermez les paramètres. Tentez à nouveau d’aller sur un site HTTPS — par exemple https://portswigger.net. La page charge sans avertissement, et l’historique du Proxy de Burp commence à se remplir. C’est le signal que tout fonctionne.

Étape 5 — Vérifier l’interception sur Burp

Retournez à Burp, onglet Proxy → HTTP history. Vous voyez la liste des requêtes que vient de faire Firefox. Cliquez sur l’une d’elles. Le panneau du bas se sépare en deux : la requête à gauche, la réponse à droite. Vous voyez les headers, les cookies, le corps. C’est exactement ce que Firefox a envoyé et reçu.

Cette vue est votre cockpit. Pendant un test, vous reviendrez ici en permanence pour observer ce qui transite. Les colonnes principales : Method (GET/POST/PUT…), URL, Status (200, 302, 404…), Length (taille de la réponse), MIME type. Cliquez sur les en-têtes de colonnes pour trier ; double-cliquez sur une cellule pour filtrer.

Étape 6 — Activer le mode Intercept pour modifier une requête

Le HTTP history est le mode passif. Pour modifier des requêtes en vol, activez l’Intercept. Onglet Proxy → Intercept, bouton « Intercept is off » → cliquez pour passer en « Intercept is on ».

Désormais, chaque requête que fait Firefox attend dans Burp jusqu’à votre validation. Allez sur Firefox, demandez n’importe quelle page. Vous voyez la requête s’afficher dans Burp. Vous avez trois choix : Forward (laisser passer telle quelle), Drop (la jeter, le navigateur recevra une erreur), ou modifier le contenu directement dans la fenêtre puis Forward.

L’intercept est puissant mais bridant — il vous bloque sur chaque requête. Pour la navigation normale, gardez-le off. Activez-le seulement le temps d’une modification ciblée. Hygiène fondamentale : « Intercept off » est l’état par défaut, « on » est l’exception.

Étape 7 — Premier exercice concret : modifier un paramètre en vol

Pour ancrer la mécanique, voici un exercice. Sur PortSwigger Web Security Academy, ouvrez le lab gratuit « Lab: Username enumeration via different responses » (catégorie Authentication). Créez un compte gratuit pour accéder aux labs si pas déjà fait. Lancez le lab — une instance dédiée vous est attribuée.

Sur Firefox, allez sur la page de login du lab. Tapez un username quelconque et un mot de passe quelconque. Activez Intercept dans Burp. Cliquez « Login » sur Firefox. La requête POST de login apparaît dans Burp. Vous voyez les paramètres dans le corps : username=alice&password=test123.

Modifiez le username dans Burp directement (changez « alice » en « administrator ») et cliquez Forward. La réponse arrive dans Firefox. Comparez les messages d’erreur entre un username valide (« Invalid password ») et un invalide (« Invalid username »). C’est l’enumération de comptes, classique d’un lab d’authentification. Vous venez d’utiliser Burp pour identifier une vulnérabilité — modestement mais réellement.

Étape 8 — Configurer Chrome ou Edge (alternative à Firefox)

Si vous préférez Chrome, la procédure diffère parce que Chrome utilise le store de certificats du système d’exploitation. Configurez d’abord le proxy via les paramètres système de Windows ou via une extension Chrome dédiée comme FoxyProxy.

Ensuite, double-cliquez sur le fichier cacert.der téléchargé. Sur Windows, l’assistant d’importation de certificat s’ouvre. Choisissez « Magasin local » → « Autorités de certification racines de confiance ». Validez l’avertissement de sécurité (oui, vous voulez vraiment ajouter cette CA). Redémarrez Chrome.

Sur macOS, l’opération passe par Keychain Access. Importez le certificat dans le trousseau « System », puis double-cliquez dessus, allez dans Trust et passez à « Always Trust » pour SSL. Redémarrez Chrome.

Cette voie est moins propre que Firefox parce que la CA est ajoutée au système entier — toutes les applications l’utilisent. Pour un poste dédié au pentest c’est OK. Pour un poste polyvalent, préférez Firefox dédié à Burp et laissez Chrome système non touché.

Étape 9 — Profil Firefox dédié à Burp

Astuce de pro : créez un profil Firefox dédié exclusivement à Burp. Lancez Firefox avec firefox --ProfileManager (Windows) ou firefox -P (Linux/Mac). Créez un nouveau profil nommé « burp ». Configurez le proxy et le certificat CA uniquement dans ce profil.

Désormais, vos sessions personnelles dans Firefox standard restent propres, et votre profil burp est l’environnement dédié au pentest avec proxy actif et CA installée. Vous lancez le bon profil selon le contexte. Pour automatiser, créez deux raccourcis bureau pointant respectivement sur les deux profils.

Cette séparation prévient une catégorie d’erreurs courantes : router accidentellement votre Gmail ou votre banque par le proxy Burp d’un client, et logger des credentials sensibles dans l’historique d’un projet d’audit. C’est le genre d’incident qui finit en notification CNIL ou en fin de mission précipitée.

Étape 10 — Vérifier votre maîtrise par un cas réel

Pour valider votre installation, déroulez le flux complet sur le lab « Username enumeration » de PortSwigger Academy : configurez le scope sur l’URL du lab, désactivez le logging hors scope, faites quelques tentatives d’authentification, observez l’historique, modifiez une requête en intercept, repérez la différence de réponse selon le username.

Si ce flux entier fonctionne sans accroc — pas d’avertissement HTTPS, requêtes loguées, intercept fonctionnel, modifications prises en compte — votre Proxy est opérationnel. Vous êtes prêt pour Repeater, qui est l’outil que vous utiliserez ensuite quasi-systématiquement.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour un test sur un client local — site WordPress de PME sénégalaise, app mobile dérivée d’une API REST, plateforme e-commerce CinetPay — la même configuration Proxy s’applique. Quelques précautions spécifiques au contexte. Premièrement, prévenez le client que le test peut générer du trafic anormal sur ses logs serveur — coordonnez avec son équipe ops pour éviter qu’on lui coupe l’accès en pensant à une attaque. Deuxièmement, sur les hébergements partagés type cPanel chez des hébergeurs locaux, certains pares-feu applicatifs bloquent le trafic Burp après quelques minutes d’activité — coordonnez l’ajout d’une exception sur votre IP source pendant la fenêtre de test.

Pour les apps de paiement mobile (CinetPay, FedaPay, Wave API, Orange Money), Burp est l’outil naturel pour vérifier les implémentations côté client : signatures de webhooks, validation des callbacks, idempotence des transactions. Intercepter les appels API entre votre app et la passerelle de paiement vous montre immédiatement si des paramètres sensibles transitent en clair, si la signature est vérifiée correctement, et si une manipulation côté client peut altérer le montant. Domaine où l’audit Burp paie immédiatement en valeur livrée au client.

Pour les tests d’intégrations bancaires locales (UBA, Ecobank, BOA), même approche : interceptez les requêtes entre l’app cliente et l’API bancaire pour vérifier les contrôles de sécurité côté client. Plusieurs implémentations vues en mission présentaient des défauts récurrents — validation du destinataire uniquement côté frontend, signature de transaction calculée par le client, contrôle anti-rejeu absent. Ces findings sont identifiés en quelques minutes via Burp Proxy + Repeater. Pour le rapport au client local, formulez l’impact en termes business : « un attaquant peut détourner les fonds d’un compte client sans interaction de la victime » plutôt que le détail technique pur.

Tutoriels frères

• Installer et configurer Burp Suite — pré-requis avant ce tutoriel.
• Repeater pas-à-pas : injections, IDOR, broken access control — la suite naturelle après le Proxy.
• Extensions BApp essentielles — pour étendre les capacités du Proxy.

Pour aller plus loin

• 🔝 Retour au pilier : Burp Suite : le guide pratique 2026
• Documentation officielle Proxy : portswigger.net/burp/documentation Proxy
• Labs Authentification gratuits : PortSwigger Academy Authentication
• Suggestion : enchaînez avec Repeater pas-à-pas pour passer du passif au manuel actif.

FAQ

Le certificat CA de Burp est-il sûr à installer ?
Oui sur votre poste de travail dédié au pentest. La CA Burp est unique à votre installation locale — elle n’est pas partagée. Le risque serait qu’un attaquant obtienne votre clé privée Burp pour signer des certificats qui seraient acceptés par votre navigateur. Cette clé reste sur votre disque local. Pour minimiser le risque, ne partagez jamais le contenu du dossier Burp et chiffrez votre disque.

Mon antivirus bloque l’installation du certificat. Que faire ?
Comportement parfois rencontré sur Windows Defender ou des AV agressifs. Ajoutez une exception sur le dossier Burp et le navigateur dédié au pentest. Si l’AV reste hostile, envisagez un poste dédié au pentest avec un AV plus léger.

Puis-je intercepter les apps mobiles ?
Oui, en configurant le proxy WiFi du téléphone vers votre IP locale et port 8080, et en installant le CA Burp sur le téléphone. Sur Android 7+, l’app cible doit explicitement autoriser les CAs utilisateur dans son network_security_config. Sur iOS, l’opération est documentée mais demande quelques manipulations supplémentaires.

Comment intercepter du trafic WebSocket ?
Burp intercepte WebSocket nativement depuis 2017. L’onglet Proxy → WebSockets history liste les frames échangées. Repeater supporte les WebSocket aussi via le module dédié.

Puis-je désactiver l’intercept pour certains sites ?
Oui. Onglet Proxy → Match and Replace, ou onglet Settings → Tools → Proxy → Match conditions. Vous excluez certaines URL ou domaines de l’intercept tout en gardant le logging passif. Utile pour exclure les CDN qui font du bruit.

Mots-clés secondaires : Burp Proxy, certificat CA, intercept HTTPS, configuration Firefox, profil dédié, port 8080.