Bug bounty : choisir les bonnes fonctionnalités à tester
Comment choisir une cible en bug bounty, explorer une fonctionnalité et valider une faille sans perdre de temps ? Découvrez une méthode fondée sur l’expérience.
Bug bounty : comment choisir une fonctionnalité à tester
En bug bounty, le premier obstacle n'est pas forcément technique. Souvent, c'est simplement le choix de la cible. Une plateforme peut exposer des centaines de fonctionnalités, mais le temps d'un chercheur reste limité. S'attarder sur une zone déjà bien explorée peut faire perdre des heures. À l'inverse, passer trop vite à la suivante, c'est risquer de rater un comportement surprenant.
Dans un entretien publié par GitHub, le chercheur @vaib25vicky décrit une approche assez simple : il ne part pas d'une catégorie de faille à cocher. Il repère une fonctionnalité, apprend à s'en servir, puis cherche ce qui se passe quand on l'utilise autrement que prévu. À ses yeux, cette méthode colle particulièrement bien aux problèmes d'autorisation et de contrôle d'accès, parce que les défauts se cachent souvent dans les interactions entre plusieurs composants.
Voici comment transformer ça en cadre de travail : choisir une surface de recherche, l'explorer proprement, décider quand insister (ou quand passer à autre chose), et utiliser l'IA sans lui déléguer la validation. Le tout, évidemment, dans le périmètre autorisé par le programme.
Pourquoi choisir une fonctionnalité plutôt qu'une faille
Une approche classique consiste à choisir une classe de vulnérabilité (injection, contrôle d'accès, mauvaise configuration, etc.) puis à chercher cette faille partout. C'est pratique pour apprendre ou pour lancer un audit ciblé. Mais en bug bounty, ça tourne vite au mode « reproduction de scénario » : on retente ce qui est déjà documenté, parfois sans bien comprendre le produit dans lequel ça pourrait apparaître.
La démarche décrite par @vaib25vicky fait l'inverse. Tu pars d'une fonctionnalité : tu la fais fonctionner, tu comprends ce qu'elle fait, puis tu déduis la catégorie de vulnérabilité à tester. En clair : la faille dépend de ce que la fonctionnalité autorise réellement à faire.
Cette inversion compte parce qu'une faille ne « vit » pas toute seule. Elle apparaît quand le comportement attendu, les règles d'accès et ce que le système autorise réellement ne s'alignent pas. Une action de partage, un mécanisme d'invitation ou une intégration entre services peut soulever des questions différentes selon la façon dont c'est conçu. Du coup, le bon test dépend du contexte produit - pas d'une liste universelle.
La complexité comme indice, pas comme preuve
Le chercheur explique qu'il privilégie souvent les zones qui semblent complexes ou difficiles à démêler. C'est un filtre raisonnable : quand une fonctionnalité relie plusieurs rôles, ressources ou étapes, elle offre plus de variations à examiner qu'une page statique.
Mais la complexité n'est pas une preuve de faiblesse. Elle dit surtout qu'il y aura peut-être plus de choses à vérifier. Et il faut éviter le piège inverse : une interface simple peut reposer sur une logique serveur compliquée, et une fonctionnalité « sophistiquée » peut aussi être bien isolée. L'objectif n'est donc pas de courir après le compliqué pour le compliqué. C'est plutôt de repérer où plusieurs règles doivent fonctionner ensemble et vérifier qu'elles restent cohérentes.
Pour démarrer, les questions peuvent être simples :
- Qui peut effectuer cette action ?
- Sur quelle ressource ça s'applique ?
- Quels rôles ou états du compte changent le résultat ?
- La fonctionnalité communique-t-elle avec un autre service, ou une autre partie du produit ?
- Quelles limites le produit semble imposer ?
Ces questions ne remplacent pas les tests, mais elles aident à choisir où investir son temps.
Le contrôle d'accès, un fil conducteur
Dans l'entretien, @vaib25vicky dit se concentrer notamment sur l'autorisation et le contrôle d'accès, sans enfermer toute la recherche dans une seule catégorie. C'est important : une spécialité peut guider ton attention, mais elle ne doit pas t'empêcher de remarquer un comportement inattendu, même si ce n'est pas « le genre » de bug que tu vises.
Dans les produits numériques, être « connecté » ne suffit pas toujours à comprendre le risque. Il faut vérifier ce que l'utilisateur a le droit de faire, sur quelles données, et dans quelles conditions. Un contrôle peut être correct dans un parcours... et mal appliqué ailleurs. Le chercheur doit donc regarder les relations entre utilisateurs, rôles, ressources et actions, sans supposer que l'interface raconte toute l'histoire.
Et pour les organisations, la même idée est très concrète : une fonctionnalité nouvelle mérite une analyse de ses règles d'accès, pas seulement une lecture de son apparence ou de son flux principal. Pour les chercheurs, le cadre reste non négociable : tes tests doivent respecter les règles du programme, les conditions d'utilisation et les limites définies par le propriétaire.
Une méthode d'exploration en quatre étapes
Le témoignage de @vaib25vicky peut se résumer en un processus clair. Ce n'est pas une recette magique qui garantit de trouver quelque chose. C'est surtout une façon de travailler avec méthode : moins d'exploration dispersée, plus de décisions au bon moment.
1. Sélectionner une surface de recherche
Commence par lire le périmètre public : produits inclus, environnements autorisés, types de tests interdits, règles de signalement et mentions autour des données. Ce n'est pas du « papier ». Ça te dit ce que tu peux tester et ce qui peut être retenu comme preuve.
Ensuite, choisis une fonctionnalité qui te semble intéressante à comprendre. Des interactions entre plusieurs utilisateurs, rôles ou composants peuvent justifier une exploration plus poussée. Mais attention au raccourci : « intéressant » n'est pas « vulnérable ». Ta première hypothèse sert à orienter ton travail, pas à conclure.
Une règle utile : formuler une question testable avant de commencer. Par exemple : « Les restrictions prévues pour ce rôle s'appliquent-elles aussi quand l'action passe par ce parcours ? » Une question claire rend tes observations plus faciles à comparer.
2. Comprendre le fonctionnement normal
Utilise d'abord la fonctionnalité comme un utilisateur légitime, dans un contexte autorisé par le programme. Note les étapes, les rôles impliqués, et le résultat attendu. Si tu ne sais pas à quoi « ressemble » le comportement normal, tu risques de confondre une règle métier volontaire avec un vrai défaut de sécurité.
Cette phase peut paraître lente, mais elle évite une erreur fréquente : prendre pour une faille une action qui était déjà prévue par le produit. Elle aide aussi à repérer les écarts. Un résultat qui change selon le rôle, le propriétaire d'une ressource ou le parcours utilisé doit être compris avant d'être qualifié.
Garde une trace simple de tes observations : prérequis, action effectuée, résultat attendu, résultat obtenu. Un carnet de test (ou un tableau) suffit. L'idée n'est pas d'écrire une documentation énorme, mais de pouvoir reprendre ton raisonnement sans repartir de zéro.
3. Explorer les variations et les comportements inattendus
Une fois le flux normal en main, explore les variations qui comptent : rôles différents, états différents, ressources distinctes ou parcours alternatifs - toujours dans les limites autorisées. Le but n'est pas d'essayer des combinaisons « au hasard ». Tu vérifies surtout si la règle observée tient quand le contexte change.
Le chercheur décrit un moment où « quelque chose d'étrange » apparaît : un résultat incohérent, une action qui réussit alors qu'elle devrait être refusée, ou une différence inexpliquée entre deux parcours. Ce n'est pas encore une preuve. C'est une piste à reproduire et à mesurer, surtout côté impact.
À ce stade, résiste à l'envie d'élargir sans limite. Une exploration responsable cherche à confirmer le problème en limitant les effets sur le service et sur les données. Et si la preuve exige d'accéder à des informations qui appartiennent à d'autres personnes, tu t'arrêtes aux limites du programme et tu suis sa procédure.
4. Confirmer, documenter ou passer à la suite
Avant de soumettre un rapport, vérifie que le comportement est reproductible et que tu peux expliquer pourquoi c'est un problème de sécurité. Un bon rapport sépare les faits de l'interprétation : contexte, étapes de reproduction autorisées, résultat attendu, résultat obtenu et impact plausible.
Si les indices restent faibles, si le comportement s'explique par la conception du produit, ou si la piste te pousse à dépasser le périmètre, le plus raisonnable est de s'arrêter. @vaib25vicky dit passer à une autre fonctionnalité quand rien de solide ne ressort après une première exploration. Ce n'est pas « abandonner » ; c'est gérer son temps.
Et quand tu vois une anomalie reproductible, il peut être plus utile de creuser de façon ciblée que de changer tout de suite de cible. Le bon équilibre dépend de la qualité du signal. Une hypothèse fragile ne mérite pas une journée entière « par principe ». À l'inverse, une anomalie cohérente et à fort impact peut justifier une analyse plus approfondie.
IA, nouvelles fonctionnalités et limites du chercheur
@vaib25vicky présente l'IA comme un assistant qui fait gagner du temps, mais qu'il faut diriger. Le point clé, c'est que l'outil ne choisit pas la bonne direction à ta place. En recherche sécurité, cette limite compte beaucoup : un modèle peut proposer une piste, résumer une documentation ou t'aider à organiser tes observations... mais il ne peut pas transformer automatiquement une hypothèse en vulnérabilité confirmée.
Ce que l'IA peut apporter
Bien utilisée, l'IA accélère certaines tâches en amont : reformuler une hypothèse, structurer une liste de questions, résumer un document public ou clarifier la structure d'un rapport. Elle peut aussi servir de partenaire de réflexion - à condition de tout vérifier et de ne pas lui transmettre de données sensibles ou de secrets liés au programme.
Et surtout : un résultat fluide n'est pas forcément exact. L'IA peut manquer le contexte d'autorisation, inventer un comportement du produit, ou te pousser vers une piste hors périmètre. Donc toute sortie « utile » doit être recoupée avec des sources autorisées et des tests que tu maîtrises.
La règle de l'entretien est claire : ne jamais soumettre une découverte que tu n'as pas confirmée toi-même. Ça vaut pour l'IA comme pour n'importe quel outil, un billet de blog, ou une hypothèse venant d'un autre chercheur. La responsabilité du rapport reste la tienne.
Les produits intégrant l'IA ne font pas disparaître les fondamentaux
Les fonctionnalités avec de l'IA peuvent demander des questions un peu différentes. Mais @vaib25vicky estime que beaucoup de problèmes à fort impact restent liés à des sujets très connus : autorisations, garde-fous insuffisants, ou capacités oubliées. Autrement dit, « IA » ne remplace pas l'analyse du produit et de ses règles d'accès.
Il faut comprendre ce que fait la fonctionnalité, qui peut l'utiliser, quelles données elle traite, et quelles limites s'appliquent. Les détails varient selon le service. Donc ce serait une erreur de réduire l'analyse à une méthode unique ou de supposer que tous les systèmes d'IA posent exactement les mêmes risques.
Pour les équipes produit, ça veut dire : une nouveauté alimentée par l'IA doit être examinée dans son contexte (droits, données, intégrations, et comportements inattendus). Et pour les chercheurs, le principe reste le même que sur le reste du web : comprendre le flux avant de conclure, tester dans le périmètre prévu, et documenter ce qui a été observé réellement.
La patience fait partie de la méthode
Le conseil que le chercheur aurait aimé recevoir au début est assez simple : ça prend du temps. En bug bounty, ne rien trouver immédiatement ne prouve pas que l'approche est mauvaise, ni que la fonctionnalité est « sûre ».
Mais la patience ne veut pas dire s'acharner sans critères. Fixe une première période d'exploration, définis ce que tu veux vérifier, puis réévalue la qualité des signaux. Si tu n'apprends plus rien et qu'aucune hypothèse précise ne se dégage, passer à une autre surface est souvent la décision la plus rationnelle.
Les pratiques et les critères de récompense changent selon les programmes. Dans le contenu à l'origine de cet entretien, GitHub indique notamment avoir réorienté son dispositif vers la qualité et l'impact des rapports, et décrit alors un programme VIP sur invitation, avec des récompenses pouvant aller jusqu'à 30 000 dollars (ou davantage) pour des découvertes critiques. Ces montants et critères ne sont pas universels et peuvent évoluer : relis toujours les règles officielles du programme GitHub avant de participer.
Conclusion : privilégier la qualité à la quantité
La méthode de @vaib25vicky tient en une idée : d'abord comprendre la fonctionnalité, ensuite décider quelle faille chercher. Observer le fonctionnement normal, tester des variations qui ont du sens, puis confirmer les anomalies aide à mieux utiliser son temps qu'une chasse « au hasard ».
L'IA peut accélérer certaines étapes, mais elle ne remplace ni le jugement, ni la validation, ni la responsabilité du chercheur. Et la patience n'a de valeur que si elle s'accompagne d'un critère clair : continuer ou changer de cible.
Si tu participes à un programme de bug bounty, commence par lire le périmètre, puis choisis une fonctionnalité que tu peux explorer proprement. Un rapport solide et confirmé vaut mieux qu'une longue liste de soupçons. Pour aller plus loin, consulte les ressources du GitHub Security Lab et les conditions du programme visé avant de tester.