Burp Repeater pas-à-pas : tester injections, IDOR, broken access control (2026)

📍 Article principal du cluster : Burp Suite : le guide pratique 2026
Cet article fait partie du cluster « Burp Suite 2026 ». Pour la configuration préalable du Proxy, voir Intercepter sa première requête.

Cadre éthique préalable. Tous les tests décrits ici se font dans des labs prévus à cet effet (PortSwigger Web Security Academy gratuite, DVWA, OWASP Juice Shop), sur des applications que vous possédez, ou dans le scope d’un programme de bug bounty officiel. Toute exploitation hors de ces périmètres est une infraction pénale.

Repeater est l’outil que vous utiliserez le plus en pentest manuel. Vous prenez une requête capturée, vous la rejouez en variant un paramètre, vous observez la réponse. Cette boucle simple — modifier, envoyer, observer — couvre 80 % du travail d’investigation. Ce tutoriel détaille les flux qui paient : SQL injection, XSS, IDOR, broken access control, mass assignment, content-type confusion, host header injection.

Prérequis

• Burp Suite installé et Proxy configuré. Voir tutoriels précédents du cluster.
• Un compte gratuit sur PortSwigger Web Security Academy pour les exemples.
• Notions HTTP de base : verbes GET/POST/PUT, headers, cookies, codes de retour.
• Niveau : débutant à intermédiaire.
• Temps estimé : 90 minutes pour parcourir, plus le temps de pratique sur les labs.

Étape 1 — Envoyer sa première requête à Repeater

Dans Burp, ouvrez l’onglet Proxy → HTTP history. Cliquez sur n’importe quelle requête intéressante — typiquement une POST de login ou une GET avec des paramètres. Clic droit → Send to Repeater (raccourci Ctrl+R).

Basculez sur l’onglet Repeater. Vous voyez la requête à gauche, et un panneau vide à droite pour la future réponse. Cliquez sur le bouton bleu Send ou utilisez Ctrl+Espace. La réponse apparaît à droite — code de retour, headers, corps. Vous venez de rejouer manuellement la requête originale.

Le pouvoir de Repeater est dans la modification. Modifiez n’importe quoi à gauche — un paramètre, un header, le corps — et renvoyez. La nouvelle réponse écrase l’ancienne. Pour conserver plusieurs essais, dupliquez l’onglet Repeater (Ctrl+T puis Send to Repeater à nouveau, ou clic droit sur l’onglet → Duplicate). Vous pouvez avoir des dizaines d’onglets Repeater en parallèle, chacun avec une variante de la requête.

Étape 2 — Tester une SQL injection en union-based

Sur PortSwigger Academy, ouvrez le lab gratuit « SQL injection UNION attack, determining the number of columns returned by the query ». Lancez l’instance. Sur Firefox configuré sur Burp, naviguez sur la page boutique du lab et cliquez sur une catégorie — par exemple « Gifts ». L’URL devient /filter?category=Gifts.

Cette requête est dans votre HTTP history. Envoyez-la à Repeater. Modifiez le paramètre :

GET /filter?category=Gifts'+ORDER+BY+1-- HTTP/2

Envoyez. Si la réponse est 200 OK avec contenu normal, la requête a fonctionné — il y a au moins une colonne. Incrémentez : ORDER BY 2, ORDER BY 3… Quand la réponse passe en 500 Internal Server Error, vous avez dépassé le nombre de colonnes. Le dernier nombre qui retourne 200 est le nombre de colonnes. Le lab attend cette information pour valider.

Cette technique — déterminer la structure de la requête en backend par observation des codes de retour — illustre exactement la philosophie de Repeater : modification ciblée, observation de la réponse, déduction. Aucun automatisme, juste de la patience d’investigation.

Étape 3 — Tester un IDOR (Insecure Direct Object Reference)

L’IDOR est l’une des classes de vulnérabilités les plus fréquentes en bug bounty et payent souvent bien. Le principe : une application identifie une ressource par un identifiant dans l’URL ou un paramètre, et ne vérifie pas que l’utilisateur authentifié a le droit d’y accéder.

Sur PortSwigger Academy, ouvrez le lab « Insecure direct object references ». Le lab simule une fonction de chat — vous accédez à votre transcript via une URL du type /download-transcript/2.txt. Cliquez sur le bouton « View transcript » de votre conversation. La requête apparaît dans HTTP history.

Envoyez-la à Repeater. Vous voyez :

GET /download-transcript/2.txt HTTP/2
Host: lab-id.web-security-academy.net

Modifiez l’identifiant : 1.txt, 3.txt, etc. Envoyez. Si vous récupérez le transcript d’une autre conversation que la vôtre — qui contient peut-être un mot de passe en clair partagé par un autre utilisateur — vous avez un IDOR. Le lab valide précisément ce flux : le transcript 1 contient le mot de passe d’un compte de support qu’on peut utiliser pour escalader.

L’IDOR est partout en pratique : URLs avec ID séquentiels, GUIDs prédictibles, paramètres user_id dans le corps, identifiants de fichiers, numéros de commande. Repeater est l’outil de choix pour énumérer rapidement et observer les réponses.

Étape 4 — Tester un broken access control via header manipulation

Variante de l’access control : certaines applications décident des permissions selon des headers que le frontend envoie mais qui ne sont pas vérifiés sérieusement côté backend. Headers classiques à tester : X-Forwarded-For, X-Original-URL, X-Rewrite-URL, Referer, Origin.

Sur Repeater, prenez une requête vers une URL admin (par exemple /admin) qui retourne 403 Forbidden quand vous n’êtes pas admin. Ajoutez le header :

X-Forwarded-For: 127.0.0.1

Renvoyez. Certains backends mal codés appliquent une politique « si la requête vient de localhost, considérer comme admin ». Dans ce cas, votre 403 devient 200. Vulnérabilité connue, et trouvable régulièrement en bug bounty sur des applications qui ont des règles de filtrage internes mal pensées.

Autres tests utiles : X-Original-URL: /admin sur une requête vers /, qui peut faire que le serveur traite la demande comme si l’URL était /admin sans passer par le filtrage de chemins habituel. Anciennes versions de divers proxies inverses présentaient ce comportement.

Étape 5 — Tester un mass assignment

Mass assignment, c’est l’erreur d’un développeur qui binde directement la requête JSON sur l’objet métier sans whitelister les champs autorisés. Conséquence : un attaquant peut ajouter des champs non prévus dans la requête et modifier des attributs sensibles.

Cas classique : une page « Modifier mon profil » qui accepte une POST JSON avec votre nom et email. Le backend fait user.update(payload) sans filtrer. Vous ajoutez "is_admin": true dans le JSON, vous renvoyez via Repeater, et selon la qualité du code, vous devenez admin.

POST /api/users/me HTTP/2
Content-Type: application/json

{
  "email": "moi@exemple.com",
  "name": "Test",
  "is_admin": true,
  "role": "administrator"
}

L’observation de la réponse vous dit si le champ est passé ou ignoré. Sur PortSwigger Academy, le module API testing contient plusieurs labs sur ce thème — recommandé pour s’entraîner sur des cas réalistes.

Étape 6 — Tester une content-type confusion

Certaines applications acceptent JSON ou XML pour la même endpoint, mais le code de validation diffère. Si vous envoyez en JSON et que les champs sont validés, vous pouvez essayer en XML — peut-être que le parser XML est moins strict ou ouvre la voie à XXE.

Modifiez le header dans Repeater :

Content-Type: application/xml

Et le corps en XML équivalent. Si la réponse est différente entre JSON et XML — code différent, comportement différent — il y a quelque chose à creuser. C’est le genre d’observation qui ouvre des chemins d’attaque non documentés. Un classique du bug bounty avancé.

Étape 7 — Tester un host header injection

Beaucoup d’applications utilisent le header Host pour générer des URLs dans leurs réponses : liens de réinitialisation de mot de passe, redirections, cookies. Si la valeur du Host n’est pas validée côté serveur, vous pouvez la falsifier pour rediriger des emails sensibles vers un domaine attaquant.

Dans Repeater, modifiez :

Host: attaquant-malicieux.test

Renvoyez la requête « mot de passe oublié ». Si l’email envoyé contient un lien vers https://attaquant-malicieux.test/reset?token=..., vous avez une vulnérabilité de password reset poisoning. PortSwigger Academy a un module entier dédié — recommandé pour comprendre toutes les variantes (X-Forwarded-Host, dual Host headers, injection de port).

Étape 8 — Utiliser les variables et auto-modify

Repeater permet de définir des variables réutilisables et des règles de match-and-replace globales. Utile quand vous testez la même structure de requête sur plusieurs endpoints.

Onglet Settings → Tools → Proxy → Match and Replace. Ajoutez par exemple une règle qui remplace systématiquement le header User-Agent par votre identifiant de pentester. Toutes les requêtes envoyées par Burp porteront cette signature — utile pour que l’équipe SOC du client puisse identifier votre trafic d’audit dans ses logs.

Étape 9 — Comparer les réponses avec Comparer

Quand deux requêtes diffèrent légèrement et produisent des réponses qui semblent différentes, l’œil nu rate des détails. L’outil Comparer aligne deux réponses côte à côte et surligne les différences au caractère ou à la ligne près.

Dans Repeater, clic droit sur la requête → Send response to Comparer. Faites une autre variante, envoyez aussi sa réponse à Comparer. Onglet Comparer : sélectionnez les deux entrées et cliquez « Words » ou « Bytes ». Burp affiche les différences.

Cas d’usage typique : vous testez l’enumération de comptes en login — une réponse pour utilisateur valide, une pour invalide. À l’œil, les deux réponses semblent identiques. Comparer montre que la réponse pour utilisateur valide a un Content-Length différent de 2 octets — différence invisible sur l’écran mais détectable par Burp. Vulnérabilité confirmée.

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

Pour valider, choisissez un lab Authentication ou Access Control sur PortSwigger Academy que vous n’avez pas encore fait. Lancez l’instance. Naviguez l’application « comme un utilisateur normal » pendant cinq minutes pour comprendre la mécanique. Identifiez la requête qui semble la plus sensible (login, reset password, modification profil, accès admin).

Envoyez-la à Repeater. Listez sur papier les modifications à tester : changer un ID, ajouter un header, modifier le corps, changer le verbe HTTP. Testez-les une par une et observez les réponses. Quand vous tombez sur un comportement inattendu, creusez avec d’autres modifications.

Si vous résolvez le lab en moins de 30 minutes après avoir compris l’app, votre Repeater est opérationnel. Sinon, lisez le walkthrough officiel pour identifier les angles que vous avez ratés et ré-essayez sur un lab similaire.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour un audit sur une application e-commerce sénégalaise ou un site métier ivoirien, les classes de vulnérabilités à prioriser dans Repeater sont, dans l’ordre : IDOR sur les ressources clients (commandes, profils, factures), broken access control sur les zones admin, injection de paramètres dans les flux de paiement mobile (CinetPay, FedaPay, Wave callback), mass assignment sur les API REST des apps mobiles dérivées. Ces quatre classes représentent en pratique 70 % des findings réels sur le marché ouest-africain.

Pour les tests d’intégrations de paiement mobile, attention particulière au flux de signature des webhooks. Beaucoup d’implémentations vérifient mal la signature côté merchand, ce qui ouvre la voie à un attaquant qui forge un webhook « paiement validé » pour un montant qu’il n’a pas payé. Repeater permet de tester ces scénarios en quelques minutes — modifier la signature, modifier le montant, observer si le serveur valide quand même.

Pour le rapport au client, gardez en tête que les pentesters ouest-africains font face à un public qui découvre souvent ces concepts. Documentez chaque finding avec : la requête originale, la requête modifiée, la réponse observée, l’impact business concret. Une capture Burp en annexe vaut mille mots techniques.

Tutoriels frères

• Proxy + certificat CA — pré-requis avant Repeater.
• Intruder : sniper, pitchfork, cluster bomb — automatiser ce que Repeater fait à la main.
• Burp + JWT et OAuth — manipuler des tokens via Repeater.

Pour aller plus loin

• 🔝 Retour au pilier : Burp Suite : le guide pratique 2026
• Documentation Repeater : portswigger.net/burp/documentation Repeater
• Labs Access Control : PortSwigger Academy Access Control
• Suggestion : enchaînez avec Intruder pour automatiser les fuzzings massifs.

FAQ

Repeater conserve-t-il l’historique de mes envois ?
Oui, chaque onglet Repeater conserve l’historique de la requête initiale plus toutes les variantes successives. Vous pouvez naviguer entre les versions avec les flèches en haut du panneau requête. Sur Pro, l’historique est stocké dans le projet et persiste entre sessions.

Puis-je rejouer une requête HTTP/2 ou WebSocket dans Repeater ?
Oui pour HTTP/2 (depuis Burp 2022). Pour WebSocket, un onglet dédié WebSocket Repeater dans Pro permet de rejouer des frames individuelles.

Comment automatiser une boucle sur plusieurs IDs sans utiliser Intruder ?
Pour deux ou trois variantes, faites-le à la main dans Repeater. Pour une dizaine ou plus, c’est précisément le rôle d’Intruder. Voir le tutoriel dédié.

Mes injections SQL ne marchent pas. Pourquoi ?
Causes courantes : encoding URL incorrect, WAF qui filtre le payload, escape côté backend qui neutralise les guillemets. Burp ne gère pas tous les encodings automatiquement — vérifiez le payload en mode Raw, comparez avec ce qui passe sur le réseau.

Repeater consomme-t-il beaucoup de mémoire ?
Modérément. Chaque onglet stocke les requêtes/réponses en RAM. Pour un projet long avec cinquante onglets et des réponses lourdes, comptez quelques centaines de Mo. Fermez les onglets terminés régulièrement pour garder la session fluide.

Mots-clés secondaires : Burp Repeater, SQL injection union, IDOR, broken access control, mass assignment, host header injection, content-type confusion.