Face à une application Web, un scanner automatisé peut détecter certains problèmes évidents, mais il ne comprendra jamais la logique métier de l'application : à quoi sert ce paramètre, pourquoi cet utilisateur ne devrait pas pouvoir voir cette ressource, ce que signifie vraiment « accès autorisé » dans ce contexte précis. C'est précisément l'espace que Burp Suite est conçu pour occuper. Plutôt que d'automatiser entièrement le test, il place le testeur au centre du processus : c'est lui qui observe le trafic, formule des hypothèses, et les vérifie manuellement en modifiant et en rejouant les requêtes.

Ce que fait réellement Burp Suite

Techniquement, Burp Suite est un proxy web : il se place entre le navigateur et l'application testée, et laisse transiter, intercepter ou modifier chaque requête et chaque réponse HTTP. Il existe en version Community (gratuite, avec des fonctionnalités manuelles suffisantes pour débuter) et en version Professional (qui ajoute notamment un scanner actif complet et l'automatisation de certaines tâches). Pour découvrir l'outil et ses concepts fondamentaux, la version Community est largement suffisante.

Mettre en place le proxy et intercepter le trafic

La première étape consiste à configurer le navigateur pour qu'il fasse transiter tout son trafic par Burp, généralement sur le port local 127.0.0.1:8080. Une fois cette configuration effectuée, chaque requête émise par le navigateur passe par Burp avant d'atteindre le serveur, ce qui permet de l'observer, de la mettre en pause, ou de la modifier avant qu'elle ne parte réellement.

La majorité du trafic Web actuel étant chiffré en HTTPS, intercepter ce trafic sans avertissement du navigateur nécessite d'installer le certificat racine généré par Burp dans le magasin de certificats de confiance de la machine ou du navigateur utilisé pour les tests. Cette étape, purement technique, est indispensable et ne doit bien sûr être réalisée que sur un environnement de test dédié, jamais sur un poste de production.

Définir un périmètre avec Target

Avant de commencer à tester activement, l'onglet Target permet de définir précisément le périmètre de l'application concernée, en incluant les domaines et sous-domaines autorisés par le mandat de test et en excluant tout le reste. Cette étape, souvent négligée par les débutants, évite deux problèmes courants : envoyer par erreur du trafic de test vers des services tiers non couverts par l'autorisation (fournisseurs d'authentification externes, CDN, outils d'analytics), et se noyer dans un volume de requêtes hors sujet qui complique l'analyse.

Repeater : le cœur du travail manuel

L'onglet Repeater est sans doute la fonctionnalité la plus utilisée d'un test manuel. Il permet de prendre une requête capturée par le proxy, de la modifier librement — un paramètre, un en-tête, une valeur de cookie, le corps d'une requête POST — puis de l'envoyer et d'observer précisément la réponse du serveur, autant de fois que nécessaire.

C'est via Repeater que se testent concrètement des scénarios comme le contrôle d'accès horizontal : un utilisateur authentifié peut-il, en modifiant simplement un identifiant numérique dans l'URL ou dans le corps de la requête, accéder aux données d'un autre utilisateur que lui ? C'est également l'outil de choix pour tester manuellement des injections, en modifiant un paramètre pour y insérer un caractère spécial ou une charge utile ciblée, puis en observant si la réponse du serveur trahit un comportement anormal (message d'erreur, changement de structure de la réponse, délai de réponse inhabituel).

Intruder : automatiser des tests répétitifs

Lorsqu'un même test doit être répété avec de nombreuses valeurs différentes — une liste de noms d'utilisateurs, une série de payloads d'injection, une plage d'identifiants numériques — l'onglet Intruder permet d'automatiser cet envoi en masse, en définissant les positions à faire varier dans la requête et la liste de valeurs à tester, puis en analysant les réponses obtenues pour repérer celles qui sortent du lot. C'est typiquement l'outil utilisé pour tester systématiquement une liste de noms d'utilisateurs communs sur un formulaire de connexion, ou pour vérifier si un identifiant de session suit un schéma prévisible en observant plusieurs valeurs générées successivement.

Decoder et Comparer : les outils du quotidien

Deux autres onglets, plus discrets, s'avèrent utiles au quotidien. Decoder permet d'encoder ou de décoder rapidement une valeur dans différents formats (Base64, URL, hexadécimal), ce qui est précieux lorsqu'un paramètre applicatif transporte une donnée encodée qu'il faut comprendre ou manipuler avant de la réinjecter. Comparer, de son côté, permet de mettre côte à côte deux requêtes ou deux réponses pour repérer précisément ce qui diffère entre elles — extrêmement utile pour identifier ce qu'un changement de paramètre a réellement modifié dans le comportement de l'application, notamment lorsque la différence n'est pas visible à l'œil nu dans une réponse volumineuse.

Un scénario concret : tester un contrôle d'accès

Pour illustrer comment ces outils s'articulent en pratique, prenons un scénario courant. Un testeur se connecte à une application avec un compte de test à faibles privilèges, puis navigue normalement jusqu'à la page qui affiche les informations de son propre profil. Le proxy capture la requête correspondante, qui contient un identifiant numérique propre à ce compte. Cette requête est envoyée vers Repeater, où le testeur modifie uniquement cet identifiant pour tenter d'accéder au profil d'un autre utilisateur. Si la réponse renvoie effectivement les données d'un autre compte, sans qu'aucune vérification d'autorisation n'ait bloqué la demande, la faille de contrôle d'accès est confirmée. Si le test doit ensuite être répété sur une plage entière d'identifiants pour évaluer l'ampleur du problème, Intruder prend le relais pour automatiser cette vérification à grande échelle. Ce scénario simple illustre bien la complémentarité entre les différents onglets de l'outil : chacun répond à un besoin précis dans une même démarche méthodique.

Le scanner : un point de départ, pas une conclusion

Le scanner intégré à Burp peut repérer des indices utiles : en-têtes de sécurité manquants, informations sensibles exposées par erreur, certaines classes de vulnérabilités connues. Il ne remplace cependant jamais l'analyse manuelle, pour une raison simple : il ne comprend pas la logique métier de l'application testée. Il peut aussi bien manquer une faille critique liée à un enchaînement de fonctionnalités spécifique à l'application, que générer des faux positifs sur des comportements en réalité tout à fait légitimes.

« Un scanner indique où regarder. C'est l'analyse manuelle, guidée par la compréhension du fonctionnement réel de l'application, qui confirme s'il y a effectivement une vulnérabilité exploitable. »

Une méthode plutôt qu'une collection d'outils

Un test d'intrusion Web efficace ne consiste pas à lancer des outils dans le désordre, mais à suivre une méthode : cartographier l'application en la parcourant normalement pour que Burp en construise la carte, identifier les points d'entrée qui manipulent des données utilisateur (paramètres d'URL, formulaires, en-têtes, cookies), puis tester méthodiquement chacun de ces points selon les catégories de vulnérabilités pertinentes pour le contexte : contrôle d'accès, injection, gestion de session, logique métier. Cette rigueur méthodologique compte souvent davantage que la maîtrise technique de l'outil lui-même.

Un cadre légal à respecter strictement

Comme pour toute technique de test d'intrusion, ces méthodes ne doivent être appliquées que sur des applications pour lesquelles vous disposez d'une autorisation explicite et documentée, dans un cadre contractuel clair précisant le périmètre, les dates et les limites du test. Tester une application sans autorisation, même dans une intention bienveillante, constitue un accès non autorisé à un système informatique et expose à des poursuites, indépendamment de la nature des failles éventuellement découvertes.