Trovare un comportamento anomalo è l’inizio di una ricerca. Perché diventi una segnalazione utile bisogna capire chi può provocarlo, su quale risorsa e con quale conseguenza. Il report deve rendere questo percorso verificabile da un’altra persona, senza obbligarla a ricostruire tutte le ipotesi del ricercatore.
Nella mia attività su HackerOne ho individuato vulnerabilità con severità e stati diversi. Il riepilogo documentato al 20 settembre 2026 include, tra gli altri risultati, un report Critical risolto per Neon, con premio di 5.000 dollari, e un report High risolto per Notion, con premio di 2.000 dollari. La pagina della ricerca distingue programmi, severità, stato e riconoscimenti.
Sono risultati di ricerca indipendente, non incarichi di consulenza o approvazioni commerciali da parte di quelle aziende. I meccanismi dei report non pubblicabili restano riservati. Qui descrivo il metodo di valutazione e uso esempi inventati, senza esporre vulnerabilità non autorizzate alla divulgazione.
Dall’anomalia all’impatto dimostrabile
Un’interfaccia che mostra un errore non dimostra automaticamente una vulnerabilità. Serve identificare una proprietà di sicurezza violata: per esempio, un utente accede a una risorsa per cui non ha autorizzazione. Il confronto deve chiarire il ruolo dell’utente, la risorsa coinvolta e il comportamento che il sistema avrebbe dovuto impedire.
Per valutare una segnalazione separerei ciò che è stato osservato da ciò che potrebbe essere una conseguenza ulteriore. Se la prova dimostra un accesso in lettura, non basta ipotizzare una modifica per presentare anche quell’impatto come confermato. Ogni passaggio aggiuntivo richiede un’evidenza pertinente e autorizzata.
Questa disciplina migliora il report e lo sviluppo: aiuta il team a capire quale confine correggere e quale comportamento verificare dopo l’intervento.
Le informazioni che rendono ripetibile una prova
Una prova deve poter essere ricostruita nel perimetro autorizzato del programma. Nel report includerei il ruolo degli account di test, lo stato iniziale, l’azione eseguita e l’esito osservato, usando soltanto i dati necessari a dimostrare il problema.
| Elemento | Che cosa chiarisce |
|---|---|
| Condizioni iniziali | Account, ruolo e configurazione necessari per ripetere il caso |
| Risultato atteso | La regola di sicurezza che dovrebbe valere |
| Risultato osservato | Il comportamento ottenuto durante la prova |
| Evidenza | Il materiale minimo che collega azione e conseguenza |
| Limiti | Ciò che non è stato provato o non rientra nel perimetro |
Le indicazioni ufficiali HackerOne sui report richiedono chiarezza, passaggi riproducibili e una spiegazione dell’impatto. Il formato aiuta, ma è la coerenza tra prova e conclusione a rendere la segnalazione valutabile.
Un esempio di descrizione da migliorare
“C’è un problema nei permessi” è troppo generico. Un esempio inventato più utile sarebbe: “Nel campione di test, un account del gruppo A legge un documento riservato al gruppo B; la stessa richiesta dovrebbe essere negata”. La descrizione identifica il confine e permette di definire una verifica.
Resterebbero da aggiungere condizioni, passaggi ed evidenze riservate al team autorizzato. Il testo pubblico dell’esempio non è una procedura per attaccare un servizio, né riproduce uno dei miei report. Mostra come trasformare un’affermazione vaga in una domanda controllabile.
La sintesi iniziale dovrebbe consentire al destinatario di capire il problema prima di leggere gli allegati. Le prove dettagliate servono poi a confermare quella sintesi, mantenendo visibile la distinzione fra fatti e ipotesi.
Un controllo negativo rende la prova più convincente
In un laboratorio autorizzato con due gruppi fittizi, A e B, una prova di lettura deve chiarire sia ciò che funziona legittimamente sia ciò che non dovrebbe funzionare. Non serve esaminare documenti di terzi: bastano oggetti creati per il test e account controllati dal ricercatore.
| Account e risorsa del laboratorio | Esito previsto | Perché serve |
|---|---|---|
| Account A, documento di A | Lettura consentita | Dimostra che la funzione è operativa |
| Account B, documento di B | Lettura consentita | Conferma che la seconda risorsa esiste |
| Account A, documento riservato di B | Nessun contenuto riservato | Controlla il confine fra gruppi |
| Account A dopo revoca dell’accesso alla propria risorsa | Accesso negato secondo la regola del sistema | Controlla l’aggiornamento dell’autorizzazione |
È una matrice inventata per spiegare il metodo, senza collegarla ai programmi citati nel mio registro. La categoria Broken Object Level Authorization, descritta da OWASP API1:2023, riguarda proprio il controllo dell’azione sul singolo oggetto. Il nome della categoria aiuta a classificare; la prova deve comunque dimostrare che l’accesso violi una regola reale.
Prima di concludere, controllerei spiegazioni alternative: il documento era condiviso pubblicamente? L’account appartiene a entrambi i gruppi? La schermata mostra soltanto un titolo già pubblico? Senza questi controlli, un’osservazione corretta può sostenere una conclusione sbagliata. Nel report terrei separati il contenuto effettivamente letto e le possibilità ulteriori non provate.
Il retest deve conservare anche la funzione legittima
Dopo una correzione, ripetere soltanto la richiesta vietata lascia una domanda aperta: la funzione ora rifiuta tutto? Nel campione ripeterei anche le letture consentite, usando dati e sessioni ripristinati in modo coerente. Il risultato utile è che il confine funzioni e che l’uso autorizzato resti disponibile.
Conserverei versione o data della correzione verificata, condizioni della prova e risultato osservato. Un diverso codice HTTP può aiutare a diagnosticare, ma la verifica riguarda anche i dati restituiti e gli effetti prodotti. Non trasformerei un retest circoscritto in una certificazione dell’intera applicazione.
Per leggere la gravità, la guida FIRST a CVSS v4.0 precisa che il punteggio Base descrive la severità e non basta, da solo, a valutare il rischio nel contesto dell’organizzazione. Nel report occorre quindi spiegare precondizioni e conseguenza osservata, oltre a riportare la classificazione concordata. Qui non ricalcolo né attribuisco vettori CVSS ai report riservati.
Severità, stato e premio raccontano cose diverse
La severità riguarda la valutazione dell’impatto. Lo stato descrive il punto del processo di gestione. Il premio è un riconoscimento economico secondo il programma. Un report in triage non va presentato come già risolto; un premio non dimostra che il meccanismo sia pubblico.
Anche un duplicato richiede una descrizione precisa. Può avere ricevuto un riconoscimento, ma non equivale a una nuova vulnerabilità unica. Nel portfolio mantengo queste distinzioni perché permettono di leggere i risultati senza gonfiarli né nascondere il lavoro svolto.
Per chi valuta un ricercatore, il totale dei premi è quindi soltanto una parte del quadro. Contano anche qualità delle prove, gestione del confronto con il team e capacità di mantenere le conclusioni entro ciò che è stato verificato.
Che cosa si può pubblicare
La divulgazione dipende dalle regole del programma e dal processo concordato. Le linee guida HackerOne sulla disclosure distinguono impostazioni e condizioni diverse. Prima di pubblicare un meccanismo o materiale del report, occorre verificare il permesso applicabile a quel caso.
Si può raccontare l’attività al livello consentito, preservando dettagli riservati e dati di terzi. Nella pagina della ricerca i risultati sintetici e il laboratorio illustrativo hanno ruoli separati: i primi documentano il lavoro, il secondo ne rende comprensibile un criterio.
Portare questo metodo nello sviluppo di un prodotto
Lo stesso approccio può aiutare a progettare i controlli di un’applicazione aziendale. Si definiscono ruoli, risorse e azioni consentite; si preparano account e dati di prova; si confronta il risultato con la regola attesa. Il perimetro e le modalità di test vanno concordati prima dell’attività.
È particolarmente utile nelle integrazioni AI, dove il modello può richiamare strumenti o cercare documenti. Il controllo deve valere nel componente che esegue l’azione. Una risposta del modello che dichiara di rispettare i permessi non costituisce, da sola, la prova che quei permessi siano applicati.
Una lettura per approfondire
HackerOne
“Clearly state what should happen versus what actually happens.”
Il confronto fra comportamento atteso e osservato aiuta a individuare il confine violato. È anche il criterio dell’esempio pubblico: la gravità deve restare collegata alla prova, senza aggiungere conseguenze non dimostrate.
Citazione breve in lingua originale. Fonte consultata il 24 settembre 2026.Fonti e contesto
Le letture sostengono i passaggi tecnici indicati. I fatti sul mio lavoro rimandano al caso del portfolio; i campioni inventati sono segnalati nel testo.
- Quality ReportsHackerOne
La citazione e la sua applicazione sono commentate nel riquadro precedente.
- API1: Broken Object Level AuthorizationOWASP · API Security Top 10, 2023
Il controllo dei permessi sul singolo oggetto. È un riferimento metodologico, non la classificazione dei report riservati citati nel portfolio.
- CVSS User GuideFIRST · CVSS v4.0
Come leggere il punteggio Base e distinguerlo dalla valutazione del rischio nel contesto dell’organizzazione.
Fonti ricontrollate il 24 settembre 2026. Per segnalare un errore o proporre un aggiornamento, scrivimi indicando il passaggio.
