Come Scegliere il Tuo Primo Obiettivo di Bug Bounty: Il Sistema dei 3 Filtri

In sintesi

La maggior parte dei principianti non abbandona il bug bounty per mancanza di competenze. Abbandona perché sceglie l'obiettivo sbagliato. La selezione dell'obiettivo è un'abilità che si può imparare, ed è più importante che conoscere ogni payload. Fai passare ogni programma attraverso tre filtri prima di dedicarci anche solo un'ora:

1. Dimensione dello Scope. Scegli un obiettivo che puoi mappare completamente in meno di 30 minuti.
2. Stack Tecnologico. Testa le tecnologie che già conosci.
3. Densità di Hunter. Scegli programmi dove competi contro cinque hunter, non cinquemila.

Poi esegui una checklist di recon di 2 ore, valuta l'obiettivo su 30 punti e impegnati su un singolo obiettivo per quattro settimane. È così che raggiungi la comprensione profonda in cui vivono i bug veri.

La selezione dell'obiettivo è l'abilità che nessuno insegna

Ecco la verità che nessuno ti dice. La maggior parte dei principianti non abbandona il bug bounty perché non è abbastanza in gamba. Abbandona perché apre un programma con uno scope enorme, passa settimane a far girare scanner automatici, non trova nulla e conclude di non essere all'altezza di questo campo.

La selezione dell'obiettivo è un'abilità. È più importante che conoscere ogni payload XSS. È più importante che avere venti strumenti installati. Quando scegli un obiettivo adatto al tuo livello attuale, trovi bug. Quando scegli un obiettivo troppo grande, troppo complesso o troppo affollato, ti bruci.

L'ho imparato nel modo più duro. All'inizio della mia carriera cacciavo qualunque cosa avesse una ricompensa attaccata. Ho sprecato mesi su obiettivi troppo grandi, troppo complessi o troppo affollati. Quando ho iniziato a filtrare gli obiettivi prima di testarli, i miei risultati sono cambiati immediatamente. Quella disciplina è ciò che mi ha portato a oltre 250 menzioni nella Hall of Fame da parte di organizzazioni tra cui WHO, UNESCO, BBC, Boeing, Cambridge, Sheffield, Deutsche Börse, BASF, Michelin e Philips.

Questa guida trasforma quella disciplina in un sistema semplice e ripetibile. Il Sistema dei 3 Filtri non è complicato e non richiede strumenti avanzati. Richiede solo onestà su dove ti trovi adesso come hunter. Fai passare ogni potenziale obiettivo attraverso questi tre controlli. Se un obiettivo fallisce un controllo, abbandonalo e trovane un altro.

1. Filtro 1: Dimensione dello Scope (riesci a mapparlo in 30 minuti?)

Per i tuoi primi dieci bug, scegli uno scope che sta su una sola schermata. Evita gli scope wildcard come *.target.com quando inizi. Cerca scope focalizzati come api.target.com, dashboard.target.com, o endpoint e sottodomini specifici elencati nella policy.

Perché la dimensione dello scope decide le tue probabilità

Uno scope wildcard è una trappola per i principianti. Passerai due settimane a mappare migliaia di sottodomini. Troverai un vecchio server, ti esalterai, e poi scoprirai che qualcuno lo ha segnalato due giorni fa usando l'automazione. Hai appena speso ottanta ore per imparare che un altro hunter è più veloce di te.

Gli scope grandi creano anche affaticamento decisionale. Quando hai diecimila sottodomini, non sviluppi mai una comprensione profonda di una singola applicazione. Salti da un asset all'altro. Ma i bug di logica vivono nella comprensione profonda. Gli IDOR, le race condition e la manipolazione dei prezzi vengono trovati da tester che comprendono il flusso di business meglio degli sviluppatori.

Pensala così. Se qualcuno ti chiedesse di trovare un errore in un singolo capitolo di un libro, potresti farlo in un'ora. Se ti chiedesse di trovare un errore da qualche parte in un'intera biblioteca, vagheresti per giorni e probabilmente lo mancheresti. È esattamente ciò che succede quando i principianti cacciano scope wildcard. Il bug è lì, ma stai cercando in troppi posti contemporaneamente.

Uno scope focalizzato ti costringe a comprendere ogni funzionalità. Impari come gli utenti si registrano, come fluiscono gli ordini, come vengono elaborati i pagamenti e come vengono condivisi i file. È lì che si nascondono i bug veri. Quando conosci a memoria ogni endpoint, inizi a notare i comportamenti strani: un parametro che cambia comportamento quando lo modifichi, un endpoint che non controlla correttamente i permessi. Quei momenti accadono solo quando conosci l'applicazione in profondità.

Com'è nel mondo reale

Un ricercatore di sicurezza ha condiviso la sua esperienza su Reddit dopo otto mesi di insuccessi. Era uno sviluppatore web con solide conoscenze tecniche. Ogni volta che iniziava a cacciare, elencava tutti i sottodomini di un grande obiettivo e poi li sfogliava a caso. Usava strumenti di enumerazione dei sottodomini, crawler e fetcher di URL d'archivio. Dopo aver trovato gli endpoint, non sapeva cosa fare dopo. Ha scritto che gli sembrava di dover passare un anno intero solo per trovare un minuscolo bug. Cacciava scope enormi su programmi popolari senza un piano, e la dimensione dell'obiettivo lo travolgeva completamente. Puoi leggere il thread qui: Bug bounty is insanely hard. Am I doing something wrong?

Un altro hunter ha scritto dell'errore che ha rallentato i suoi progressi per mesi. Inseguiva programmi enormi con scope ampi, cambiava obiettivo ogni pochi giorni e non si impegnava mai a comprendere a fondo una sola applicazione. Quando si è concentrato su scope più piccoli e gestibili, i suoi risultati sono cambiati immediatamente: The Bug Hunting Mistake That Slowed My Progress.

Scope ideali per i principianti

• api.target.com o mobile.target.com con meno sottodomini e asset
• Endpoint specifici come /api/v1/users o /api/v1/orders
• Singole applicazioni con ruoli utente chiari
• Negozi online con flussi di carrello e checkout

La regola: se non riesci a leggere ogni endpoint dello scope entro trenta minuti, l'obiettivo è troppo grande. Saltalo.

2. Filtro 2: Stack Tecnologico (caccia ciò che capisci)

Scegli obiettivi di cui comprendi la logica e il protocollo. Se non hai mai toccato GraphQL, non scegliere un obiettivo la cui intera API è GraphQL nativa. Se non capisci le applicazioni mobile, salta per ora gli scope mobile. Potrai imparare quelle tecnologie più avanti, ma non è da lì che si parte. Caccia ciò che conosci.

Perché un disallineamento tecnologico uccide la motivazione

Quando scegli un obiettivo costruito su una tecnologia che non capisci, passi la prima settimana a imparare la sintassi invece di trovare bug. Passi la seconda settimana a lottare con i concetti. Entro la terza settimana sei frustrato e pronto a mollare.

I principianti spesso inseguono ricompense alte su obiettivi difficili. Un payout massimo di 50.000 dollari non significa nulla se l'applicazione gira su uno stack che non sai testare. Facebook, Google e Apple hanno una sicurezza di livello mondiale e sono stati testati dai migliori hunter per oltre un decennio. Da principiante, è probabile che tu passi cento ore senza trovare nulla.

Confrontalo con un hunter che conosceva le API REST e i moduli web standard e ha trovato un bug di manipolazione del prezzo su un semplice sito PHP. L'API di checkout era una semplice richiesta POST. Niente microservizi, nessuna architettura complessa, solo un parametro di prezzo inviato dal lato client. Ha cambiato il prezzo da cinquecento dollari a due dollari, e il server l'ha accettato. Quel bug non richiedeva codice di exploit e nessun payload speciale. Richiedeva solo di comprendere una semplice richiesta POST e di chiedersi perché il prezzo arrivasse dal client. Questa è una classica vulnerabilità di logica di business, ed è esattamente il tipo di bug che puoi trovare quando la tua mente è libera di cercare difetti di logica invece di lottare con le basi.

Caso reale: la barriera di GraphQL

Un principiante ha condiviso pubblicamente la storia del suo primo bounty. Ha trovato un file JavaScript contenente una chiave API GraphQL su un obiettivo con uno scope enorme, e ha scoperto un endpoint /graphql tramite directory fuzzing. Ma c'era un problema: non sapeva nulla di GraphQL. Ha passato diversi giorni a fare ricerche, a imparare e a raccogliere strumenti solo per capire lo schema. Ha usato la PortSwigger Academy per imparare le basi e l'estensione Burp InQL per visualizzare lo schema. Alla fine ha guadagnato un bounty di 700 dollari, ma il divario tecnologico ha quasi fatto sì che mollasse prima di iniziare. Se avesse scelto un obiettivo con API REST standard, avrebbe potuto iniziare a testare immediatamente. Storia completa: How I Got My First Bounty.

Stack adatti ai principianti

• API REST standard con endpoint GET e POST chiari (vedi la nostra guida ai test di sicurezza delle API)
• App web tradizionali con ruoli utente come Admin, User e Guest
• Flussi e-commerce con carrello, checkout e passaggi di pagamento
• Piattaforme con funzionalità di team o di invito

Stack da evitare da principiante

• Forte dipendenza dai WebSocket. Difficili da testare senza tooling personalizzato.
• GraphQL con autorizzazione complessa. Curva di apprendimento ripida.
• Scope Internet of Things o hardware. Richiedono dispositivi fisici.
• Scope blockchain o smart contract. Un insieme di competenze completamente diverso.

Se stai ancora costruendo le basi, passa prima del tempo in un home lab e nella PortSwigger Web Security Academy. Entrambi ti permettono di esercitarti sugli stack qui sopra senza alcun rischio legale.

3. Filtro 3: Densità di Hunter (evita la folla)

Trova programmi dove la competizione è bassa ma lo scope è reale. Evita la corsa ai programmi popolari. Cerca programmi di divulgazione delle vulnerabilità con piccole liste Hall of Fame, e programmi più recenti che non sono ancora stati ripuliti.

Perché la densità è un moltiplicatore nascosto

Un'alta densità di hunter significa basse probabilità. Quando cinquemila hunter guardano lo stesso obiettivo, la tua possibilità di trovare un nuovo bug scende quasi a zero. I bug facili sono stati trovati il primo giorno. I bug medi sono stati trovati la prima settimana. Ciò che resta richiede competenza profonda o condizioni molto specifiche.

I programmi popolari sulle piattaforme principali sono come punti di pesca affollati. Tutti lanciano la lenza, e le grandi prede sono rare. Sui programmi più saturi, una grande parte dei report in arrivo viene chiusa come duplicato, il che significa che anche una scoperta valida può non farti guadagnare nulla.

I programmi nascosti sono la tua arma segreta. Alcuni dei migliori obiettivi per i principianti non sono sulle prime pagine di HackerOne o Bugcrowd. Sono programmi di responsible disclosure sepolti nella pagina di sicurezza di un'azienda, o self-hosted tramite un file security.txt sul sito dell'azienda. Questi programmi potrebbero non pagare in denaro, ma forniscono menzioni nella Hall of Fame, swag, reputazione ed esperienza. Soprattutto, hanno pochissima competizione. Un'azienda che gestisce un VDP tramite il proprio sito potrebbe avere solo cinque o dieci hunter che le hanno mai inviato un report. Confrontalo con un programma di punta con cinquemila hunter. Dove preferiresti passare le tue due settimane?

Caso reale: dodici nomi nella Hall of Fame

Un hunter ha guadagnato il suo primo bounty da 1.000 dollari evitando del tutto la folla. Invece di buttarsi su un programma popolare, ne ha scelto uno pubblico e maturo e, dopo quasi due mesi, ha rivisitato i suoi appunti e ha ricontrollato il robots.txt. Ha trovato un percorso disallow che puntava a un pannello admin che restituiva un 403, il che confermava l'esistenza della risorsa, e poi ha trovato un modo per aggirare la restrizione. Il dettaglio chiave è che ha scelto un obiettivo focalizzato e a bassa competizione, il che gli ha permesso di dedicare tempo a dettagli come il robots.txt senza preoccuparsi che cinquecento altri hunter li avessero già controllati: My First Bug Bounty: How I Earned $1,000.

Un altro ricercatore ha trovato un VDP fintech con esattamente dodici nomi nella Hall of Fame e uno scope di sole due API. Poiché la competizione era così bassa, ha testato a fondo ogni funzionalità per due settimane e ha trovato tre bug validi in funzionalità secondarie che altri hunter avevano saltato. Su un programma con cinquecento hunter attivi, quei bug sarebbero spariti nella prima settimana.

Come misurare la densità di hunter

1. Controlla la pagina Hall of Fame. Se ha 200+ nomi, il programma è saturo. Da dieci a cinquanta nomi significa che hai spazio per lavorare.
2. Guarda l'età del programma. Un programma lanciato sei mesi fa con trecento report risolti è probabilmente ripulito. Un programma lanciato tre settimane fa con cinque report è fresco.
3. Controlla l'ultima attività. Se l'ultimo report risolto è di ieri, gli hunter ci stanno lavorando attivamente. Se l'ultimo report è di tre settimane fa, gli hunter sono andati avanti ma i bug potrebbero essere ancora lì.

Trovare programmi nascosti con i Google dork

Il Google dorking usa operatori di ricerca avanzati per far emergere programmi a bassa competizione:

site:com inurl:responsible-disclosure
site:de inurl:security.txt
inurl:.well-known/security.txt "contact"
site:io "report a vulnerability"

Quando trovi un file security.txt (standardizzato come RFC 9116), leggilo con attenzione. Se elenca un contatto e una pagina di acknowledgments, hai trovato un obiettivo con competizione praticamente nulla.

4. Esegui una checklist di recon di 2 ore prima di testare

Una volta che un obiettivo supera tutti e tre i filtri, non iniziare a lanciare payload. Dedica due ore a una ricognizione strutturata. Se non riesci a rispondere a queste domande in 120 minuti, l'obiettivo è troppo complesso o i tuoi appunti vanno migliorati.

Ora 1: mappa la superficie d'attacco

Il tuo obiettivo nella prima ora è comprendere l'intera superficie d'attacco, non ancora trovare bug.

• Registra due account. Ti servono due account per testare gli IDOR e altri problemi di controllo degli accessi.
• Identifica tutti i ruoli utente. Guest, User, Admin, Vendor. Uno può scalare verso un altro?
• Elenca ogni funzionalità. Login, reset password, aggiornamento profilo, upload di file, condivisione, checkout.
• Trova la documentazione dell'API. Cerca collezioni Swagger o Postman, oppure leggi le chiamate JavaScript del frontend.

Ora 2: cerca i frutti a portata di mano

• Flusso di reset password. Il token è prevedibile? Puoi forzarlo con il brute force?
• Upload di file. C'è un filtro sulle estensioni? Puoi caricare HTML o JavaScript?
• Aggiornamento profilo. Puoi cambiare la tua email con quella di un utente esistente?
• Flussi di condivisione o invito. Puoi invitarti alla risorsa di un altro utente?
• Flusso di checkout o pagamento. Il prezzo finale viene inviato dal client?

Se finisci questa checklist e non trovi nulla, non mollare. Hai testato solo la superficie. Ma se trovi anche solo un comportamento strano, come un 200 OK su un ID modificato o un rate limit mancante, hai una pista. Seguila. Nuovo agli strumenti di recon? Inizia con il nostro tutorial su Nmap e i comandi Linux essenziali.

5. Valuta ogni obiettivo con la Scorecard dell'Obiettivo

Usa questa scorecard per ogni obiettivo prima di dedicarci anche solo un'ora. Richiede cinque minuti e ti risparmierà settimane di sforzi sprecati.

Guida ai punteggi:

• Da 25 a 30: Obiettivo di prima scelta. Impegnati per quattro settimane.
• Da 18 a 24: Accettabile. Buono per imparare, ma gestisci le aspettative.
• Sotto 18: Abbandonalo. Trova qualcosa di meglio. Il tuo tempo è troppo prezioso.

Tieni questa scorecard nei tuoi appunti ed eseguila prima di ogni nuovo obiettivo.

6. Impegnati su un obiettivo per quattro settimane

Una volta che un obiettivo supera i filtri e supera la scorecard, impegnati su di esso per quattro settimane. Non aggiungere un secondo obiettivo finché non hai passato quattro settimane intere sul primo.

La maggior parte dei principianti sono turisti degli obiettivi. Cacciano un programma per tre giorni, non trovano nulla e passano al successivo. Non sviluppano mai la comprensione profonda necessaria per trovare i difetti di logica. E i bug di logica non si rivelano al terzo giorno. Si rivelano al giorno dieci, quando noti che l'endpoint di eliminazione account si comporta diversamente se lo invii due volte. Si rivelano al giorno venti, quando ti rendi conto che l'API mobile ha un parametro che l'app web non usa mai. Si rivelano al giorno trenta, quando comprendi il flusso di business meglio dello sviluppatore.

Questa disciplina è scomoda. Sembra lenta. Ma è così che costruisci il riconoscimento dei pattern che rende la caccia naturale più avanti. Se non trovi alcun bug in quattro settimane, rivedi i tuoi appunti prima di andare avanti. Hai mancato una funzionalità? Hai saltato un flusso? Solo allora considera di cambiare.

7. Dove si colloca il bug bounty nella tua carriera

Il bug bounty è uno dei modi più rapidi per dimostrare pubblicamente le competenze di sicurezza offensiva, ma raramente è tutta la storia. La stessa disciplina di selezione dell'obiettivo (focus, profondità e pazienza) è ciò che i datori di lavoro cercano nei penetration tester e nei red teamer. Se stai costruendo una carriera, abbina la tua caccia all'apprendimento strutturato: un percorso di carriera in cybersecurity chiaro, le certificazioni giuste per principianti, e la prova di saper lavorare in sicurezza, che costruisci in un home lab di cybersecurity. Stai cambiando settore senza un background formale? Scopri come ci si entra senza una laurea.

Leggi ogni settimana i report divulgati per allenare il tuo riconoscimento dei pattern. La PortSwigger Web Security Academy e le pagine del progetto OWASP sono gratuite, autorevoli e mappano direttamente sui bug che cercherai.

Conclusione: gioca le probabilità a tuo favore

Il bug bounty non è una lotteria. Si tratta di giocare le probabilità a tuo favore.

Non devi hackerare Google per essere un vero hacker. Devi trovare un obiettivo adatto alle tue competenze attuali, comprenderlo a fondo e cacciare dove gli altri non guardano. Il Sistema dei 3 Filtri trasforma il tentativo casuale in un processo. La Dimensione dello Scope ti tiene focalizzato. Lo Stack Tecnologico ti tiene efficace. La Densità di Hunter ti tiene competitivo.

La tua prima menzione nella Hall of Fame si nasconde in un'API focalizzata, su un programma con altri dodici hunter, in un flusso di logica di business che a nessun altro è venuto in mente di testare. Usa i filtri. Usa la scorecard. Impegnati per quattro settimane. Vai a trovarla.