Éviter les doublons & N/A
Maximiser votre taux d'acceptation et minimiser les efforts gaspillés
Ce que vous allez découvrir
🎯 Pourquoi c'est important
Rien n'est plus frustrant que de passer des heures sur un bug pour recevoir "Duplicate" ou "Not Applicable". Comprendre pourquoi les rapports sont rejetés vous aide à chasser plus intelligemment. Les chasseurs les plus efficaces ont un signal élevé (rapports valides) et peu de bruit (doublons/N/A).
🔍 Ce que vous allez apprendre
- Pourquoi les rapports sont marqués duplicate
- Pourquoi les rapports sont marqués N/A
- Stratégies pour réduire le taux de rejet
- Quand chasser sur les nouveaux vs programmes établis
- Apprendre des rejets
🚀 Votre première victoire
En 20 minutes, vous aurez des stratégies pour maximiser votre taux de rapports valides.
Compétences que vous maîtriserez
Sélection stratégique
Choisissez des programmes où vous pouvez être compétitif
Évaluation de qualité
Évaluez les découvertes avant de soumettre
Analyse des rejets
Apprenez des retours pour améliorer les futurs rapports
Optimisation du signal
Construisez un ratio valides/total solide
Comprendre les termes clés
Signal
Votre ratio de rapports acceptés (valides) sur le total soumis. Un signal élevé signifie que la plupart de vos rapports sont valides, pas des doublons ou N/A. Les plateformes utilisent le signal pour décider des invitations aux programmes privés. Visez 70%+ de signal.
Duplicate
Quelqu'un d'autre a signalé la même vulnérabilité avant vous. Le premier rapporteur obtient le crédit ; les rapports suivants sont marqués duplicate. Les doublons diminuent votre signal mais sont inévitables - l'objectif est de les minimiser.
N/A (Not Applicable)
Le rapport ne qualifie pas comme vulnérabilité de sécurité valide. Raisons incluent : hors scope, pas d'impact réel, comportement prévu ou risque connu/accepté. N/A nuit plus au signal que les doublons car ça suggère une incompréhension.
Valid/Resolved
Le rapport a été accepté comme problème de sécurité légitime. Il peut être triaged (confirmé), resolved (corrigé) ou awarded (payé). Les rapports valides construisent votre signal et réputation, menant aux invitations de programmes privés.
🔧 Checklist pré-soumission
Posez-vous ces questions avant de cliquer sur soumettre :
# VÉRIFICATION DU SCOPE
[ ] Cet asset est-il explicitement listé dans le scope ?
# Si le scope dit "app.company.com" mais vous avez trouvé le bug
# sur "api.company.com", vérifiez que api est aussi dans le scope
[ ] Ce type de vulnérabilité est-il accepté ?
# Certains programmes excluent certains types de vulnérabilités
# Vérifiez la section "Exclusions" ou "Out of Scope"
# VÉRIFICATION D'IMPACT
[ ] Ai-je démontré un impact de sécurité réel ?
# "Header manquant" seul n'est pas suffisant
# Montrez ce qu'un attaquant peut FAIRE avec ça
[ ] Puis-je reproduire cela de manière fiable ?
# Si vous ne pouvez pas le reproduire deux fois, ne soumettez pas
[ ] Une équipe sécurité raisonnable s'en soucierait-elle ?
# Pensez de leur perspective - est-ce que ça vaut d'être corrigé ?
# VÉRIFICATION DE QUALITÉ
[ ] Est-ce une CVE connue dans une dépendance qu'ils contrôlent ?
# "Votre serveur tourne Apache 2.4.49" n'est pas utile
# sauf si vous pouvez l'exploiter
[ ] L'exploitation nécessite-t-elle une interaction utilisateur irréaliste ?
# "L'utilisateur doit coller ce payload de 500 caractères" ne passera pas
# Si UNE réponse est "non" ou "pas sûr" - reconsidérez la soumission.Rappelez-vous : Un rapport valide vaut plus que dix rejetés. Protégez votre signal.
Comprendre les rejets
"Chaque rejet est une donnée. Apprenez pourquoi et adaptez votre stratégie."
Pourquoi les rapports sont marqués duplicate
# RAISONS COURANTES DES DOUBLONS
1. Les programmes populaires attirent des centaines de chasseurs
# Les programmes les plus célèbres (Google, Meta) ont des milliers
# de personnes qui testent. Les bugs faciles sont trouvés immédiatement.
2. Les bugs évidents trouvés rapidement après le lancement
# Quand un programme lance, les chasseurs expérimentés sautent dessus
# et trouvent les bugs de surface en quelques heures.
3. Tester des vulnérabilités communes sur des endpoints évidents
# /login, /reset-password, /api/user - tout le monde teste ça
# Le XSS dans la barre de recherche principale ? Déjà trouvé.
4. Ne pas aller assez profond dans l'application
# Les tests de surface trouvent des bugs de surface (que d'autres ont trouvé)
# Les tests profonds trouvent des bugs uniques qui sont encore là.
# COMMENT RÉDUIRE LES DOUBLONS
✓ Chassez sur des programmes plus récents ou moins populaires
# Les nouveaux programmes n'ont pas été ratissés encore
# Les plateformes plus petites (Intigriti) ont moins de compétition
✓ Testez des fonctionnalités moins évidentes
# Panneaux admin, fonctionnalités premium, cas limites
# Fonctionnalités qui nécessitent une configuration pour tester
✓ Allez plus profond dans l'authentification et la logique métier
# Ces bugs nécessitent de comprendre l'application
# L'automatisation ne peut pas les trouver, donc moins de compétition
✓ Ne comptez pas uniquement sur les scanners automatisés
# Tout le monde exécute les mêmes scanners
# Découvertes de scanner = taux de doublon élevé
✓ Spécialisez-vous dans une niche
# Apps mobiles, APIs, stacks technologiques spécifiques
# Moins de chasseurs = moins de doublonsPourquoi les rapports sont marqués N/A
# HORS SCOPE
Tester *.company.com quand le scope dit app.company.com uniquement
# Solution : Lisez le scope attentivement avant de tester
Services tiers que l'entreprise ne contrôle pas
# Zendesk, Intercom, services d'analytics - pas leur code
# Solution : Vérifiez si l'asset est vraiment possédé par l'entreprise
Environnements de staging/développement explicitement exclus
# Souvent listés comme hors scope pour une raison
# PAS D'IMPACT RÉEL
Self-XSS (n'affecte que la personne qui le saisit)
# Vous ne pouvez exploiter personne d'autre - ce n'est pas une vulnérabilité
Headers de sécurité manquants sans exploit démontré
# "X-Frame-Options manquant" seul n'est pas un bug
# Besoin de montrer un clickjacking exploitable sur une page sensible
Attaques théoriques sans preuve
# "Un attaquant pourrait potentiellement..." - montrez ce que vous POUVEZ faire
# COMPORTEMENT PRÉVU
Le "bug" est en fait une fonctionnalité documentée
# Ce qui semble faux pourrait être par design
# Vérifiez la documentation avant de signaler
Rate limiting qui vous semble faible
# S'il y a UN rate limiting, ils l'ont probablement considéré
# Besoin de montrer un vrai bypass, pas "je pense que ça devrait être plus bas"
# RISQUE CONNU/ACCEPTÉ
L'entreprise est au courant et a choisi d'accepter le risque
# Décision business de laisser tel quel
# Rien que vous puissiez faireStratégies pour augmenter l'acceptation
Sélection stratégique de cible
# STRATÉGIES BASÉES SUR LE TIMING
Nouveaux programmes (30 premiers jours)
Pourquoi : Moins de compétition, plus de bugs non découverts
Comment : Filtrer par date de lancement, vérifier les sections "Nouveau"
Surveiller : Annonces de plateforme pour les nouveaux programmes
Programmes avec mises à jour récentes du scope
Pourquoi : Nouveaux assets = nouveau terrain de chasse
Comment : Suivez les programmes, vérifiez les annonces
Surveiller : Notifications "Scope étendu pour inclure..."
Applications récemment mises à jour
Pourquoi : Nouveau code = nouveaux bugs
Comment : Vérifier les blogs d'entreprise, changelogs, mises à jour d'app store
Surveiller : Annonces de fonctionnalités, mises à jour de version
# STRATÉGIES BASÉES SUR LA PLATEFORME
Plateformes moins populaires
Pourquoi : Pool de chercheurs plus petit = moins de compétition
Options : Intigriti, YesWeHack, Synack
Compromis : Moins de programmes, mais moins bondé
Industries avec moins de hackers
Pourquoi : Santé, finance, retail - moins "sexy" mais lucratif
Bonus : Ont souvent des pratiques de sécurité plus faibles
Note : Peut nécessiter une compréhension de la conformité (HIPAA, etc.)Approche de test
# ALLEZ AU-DELÀ DE L'ÉVIDENT
Testez les apps mobiles au lieu du web uniquement
Pourquoi : Moins de chasseurs testent le mobile, plus de découvertes uniques
Comment : Configurez un proxy, interceptez le trafic app, testez les APIs
Concentrez-vous sur les nouvelles fonctionnalités (vérifiez les changelogs)
Pourquoi : Le nouveau code n'a pas été testé aussi minutieusement
Comment : Suivez les blogs d'ingénierie d'entreprise, mises à jour d'app
Logique métier plutôt que vulnérabilités techniques
Pourquoi : Les scanners ne peuvent pas les trouver, nécessite une réflexion humaine
Exemples : Manipulation de prix, bypass de workflow, problèmes de permission
Tests d'API (souvent négligés)
Pourquoi : Les APIs exposent des fonctionnalités sans protections UI
Comment : Cartographiez tous les endpoints, testez l'autorisation sur chacun
# TIMING DE VOS SOUMISSIONS
Signalez rapidement quand vous trouvez quelque chose de solide
Pourquoi : Chaque heure de délai augmente le risque de doublon
Astuce : N'attendez pas un rapport "parfait" si le bug est clair
Équilibrez vitesse et qualité
Pourquoi : Les rapports précipités sont rejetés pour manque de détail
Astuce : Incluez les étapes de reproduction et l'impact, même brièvementApprendre des rejets
Analyse des patterns de doublons
Si vous obtenez des doublons sur des bugs évidents (XSS dans la recherche, IDOR sur les endpoints principaux), vous testez trop largement et êtes en compétition avec tout le monde. Solution : Allez plus profond sur moins de cibles. Apprenez une application de fond en comble. Testez des fonctionnalités qui nécessitent une configuration, des comptes premium ou des états spécifiques. Spécialisez-vous dans un domaine que les autres évitent.
Analyse des patterns N/A
Lisez attentivement les raisons de rejet. Était-ce le scope ? L'impact ? Un comportement prévu ? Chaque N/A vous apprend quelque chose sur ce qui compte comme vulnérabilité valide. Suivez vos rejets : Si vous continuez à recevoir des N/A pour "headers manquants", arrêtez de signaler les headers manquants sans exploit démontré. Ajustez votre compréhension selon les retours.
Amélioration continue
Gardez un journal des rejets. Notez la raison de chaque duplicate/N/A. Cherchez des patterns après 10-20 rejets. Avez-vous constamment des problèmes de scope ? Des problèmes d'impact ? Testez-vous les mêmes types de bugs que tout le monde ? Utilisez ces données pour ajuster votre stratégie systématiquement.
Questions fréquemment posées
Dois-je contester un duplicate/N/A ?
Seulement si vous croyez sincèrement qu'il y a un malentendu. Fournissez des preuves supplémentaires poliment : "J'aimerais clarifier l'impact..." N'argumentez pas agressivement - ça endommage votre réputation et fait perdre du temps à tout le monde. La plupart des rejets sont corrects. Acceptez-les gracieusement et apprenez des retours.
Quel est un bon taux d'acceptation ?
Les meilleurs chasseurs visent 70%+ de rapports valides. Si vous êtes en dessous de 50%, vous soumettez trop de rapports de basse qualité. La qualité plutôt que la quantité - moins de rapports, mieux validés sont plus efficaces pour votre réputation, vos gains et votre apprentissage. Un P2 solide vaut plus que cinq rapports N/A.
Comment vérifier si un bug pourrait être un doublon avant de soumettre ?
Vous ne pouvez pas savoir avec certitude, mais vous pouvez estimer : Est-ce un bug évident sur un endpoint principal ? A-t-il été trouvé par un scanner courant ? Le programme fonctionne-t-il depuis des années ? Si oui à tout, le risque de doublon est élevé. Considérez s'il vaut la peine d'investir du temps dans un meilleur rapport ou de passer à autre chose. Plus votre approche de test est unique, plus votre taux de doublon est bas.
Est-ce que ça vaut la peine de chasser sur des programmes très populaires ?
Oui, mais avec une stratégie différente. Les programmes populaires paient bien et ont un large scope, mais les bugs de surface sont partis. Le succès nécessite des tests profonds : comprendre leur stack technique spécifique, trouver des bugs dans la logique métier, tester des cas limites que les autres manquent. Si vous êtes prêt à investir le temps pour apprendre une application en profondeur, les programmes populaires peuvent être lucratifs.
🎯 Vous pouvez maximiser l'acceptation !
Sélection stratégique de cible, vérifications pré-soumission minutieuses et apprentissage des retours - vous avez maintenant les outils pour minimiser les efforts gaspillés et maximiser les découvertes valides. Rappelez-vous : le signal compte plus que le volume.
Prêt à automatiser et mettre à l'échelle votre chasse