Security Bounty Hunter

Sélectionné par Skill Harbor : un guide pratique de chasse aux vulnérabilités réglé sur une seule question : est-ce que ça paie vraiment ? Le skill privilégie fortement les chemins d'attaque atteignables à distance et contrôlés par l'utilisateur, et écarte les patterns que les plateformes de primes rejettent systématiquement comme informatifs ou hors périmètre. Dans le périmètre : SSRF via URLs contrôlées par l'utilisateur, contournement d'auth dans le middleware ou les gardes d'API, désérialisation distante et chemins upload-vers-RCE, injection SQL dans les endpoints atteignables, injection de commandes dans les handlers de requêtes, traversal de chemin dans les chemins de fichiers, XSS auto-déclenché. Explicitement ignorés sauf mention du programme : pickle.loads local uniquement, eval dans l'outillage CLI seul, shell=True codé en dur, headers de sécurité manquants seuls, plaintes génériques de rate limiting, self-XSS, injection CI hors périmètre, code de démo ou de test uniquement. Le workflow : vérifier d'abord le périmètre du programme (règles, SECURITY.md, canal de divulgation, exclusions), trouver les vrais points d'entrée (handlers HTTP, uploads, jobs d'arrière-plan, webhooks, parsers, endpoints d'intégration), utiliser l'outillage statique comme entrée de triage seulement, lire le vrai chemin de code, puis prouver l'exploitabilité avant d'écrire le rapport. Par @affaan-m, listé ici avec crédit à son créateur. Tiré du dépôt affaan-m/ECC (MIT). Bémols honnêtes : ne chassez que sur des cibles que vous êtes autorisé à tester ; une checklist n'est pas un pentest et ne soumettez jamais de findings non vérifiés. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.