Data leak nei sistemi delle giurie USA: cosa è successo davvero e cosa impariamo per la nostra privacy
Un bug banale ha aperto la porta a dati personali altamente sensibili in diversi sistemi usati dai tribunali statunitensi (e in parte canadesi) per gestire i potenziali giurati. Parliamo di nomi, indirizzi, lavoro, stato civile e persino informazioni sanitarie, accessibili con una sequenza di numeri incrementali. Sembra lontano? Non lo è. È la fotografia di un problema strutturale che riguarda anche Italia ed Europa: piattaforme pubbliche vitali affidate a fornitori sottodimensionati e misure di sicurezza minime. Ecco cosa è accaduto, perché è successo e come possiamo difenderci.
Il caso: un bug che espone i potenziali giurati
Secondo l’esclusiva di TechCrunch, alcuni siti progettati per gestire le informazioni dei potenziali giurati negli Stati Uniti e in Canada presentavano una falla tanto semplice quanto grave. In pratica, bastava modificare un numero identificativo nella URL o nei parametri della pagina per visualizzare i dati di altre persone: un ID univoco incrementale, senza controlli adeguati. Un invito a nozze per curiosi, malintenzionati e bot di scraping.
I siti vulnerabili risultavano attivi in diversi stati USA, tra cui California, Illinois, Michigan, Nevada, Ohio, Pennsylvania, Texas e Virginia. TechCrunch ha segnalato il problema al fornitore a inizio novembre; il vendor ha poi confermato e corretto la vulnerabilità. Ma il punto non è solo “se” la falla sia stata chiusa: è “come” sia stata possibile e “quanto” sia diffusa una cultura di sviluppo e procurement pubblico che tollera errori così elementari.
Che tipo di dati sono stati esposti
I moduli per i potenziali giurati raccolgono informazioni che servono a valutare idoneità, disponibilità e possibili conflitti. Il problema è che, se queste informazioni escono dal recinto, diventano oro per chi vuole profilare, truffare o ricattare. Tra i campi a rischio, secondo quanto ricostruito:
- Dati anagrafici: nome, cognome, indirizzo di casa, contatti.
- Dati occupazionali: datore di lavoro, ruolo, orari e disponibilità.
- Informazioni personali e familiari: stato civile, figli, cittadinanza.
- Elementi legali: eventuali precedenti o incriminazioni dichiarate nei questionari.
- Dati sanitari: note sulle condizioni di salute rilevanti per l’esenzione o rinvio del servizio.
Con un simile pacchetto, i rischi si moltiplicano: furto d’identità, doxxing, stalking, social engineering per colpire lavoratori e famiglie, fino a possibili forme di ricatto se emergono elementi sensibili di salute o situazioni giudiziarie delicate.
Perché è successo: l’errore che non dovrebbe esistere
ID incrementali e assenza di controllo degli accessi
La logica “ID=1, 2, 3…” senza un controllo rigoroso su chi sta accedendo a cosa è un anti-pattern noto da anni. È un classico caso di Insecure Direct Object Reference (IDOR): l’applicazione espone un identificatore prevedibile e non verifica che l’utente sia autorizzato a vedere quella risorsa. È come lasciare un faldone sul tavolo e sperare che nessuno lo apra.
Difese di base mancanti
- Autorizzazione granulare assente: mancava un check robusto per associare l’utente alla sua sola scheda.
- Rate limiting e monitoraggio carenti: senza limiti e alert, uno script può “sfogliare” migliaia di record in pochi minuti.
- Validazione lato server insufficiente: non basta nascondere campi o link lato frontend se il backend consegna comunque i dati.
- Mancanza di test e code review: una suite di test di sicurezza o un penetration test base avrebbe intercettato l’IDOR.
Qui non parliamo di attacchi zero-day o exploit avanzati: è igiene minima della sicurezza applicativa. E quando manca, il problema non è il singolo sviluppatore, ma l’intera filiera: requisiti, gare, tempi, budget, controlli.
L’impatto concreto: non solo privacy
Nei sistemi di giustizia, la riservatezza non è un vezzo: è sicurezza. I giurati possono essere esposti a pressioni indebite, contatti indesiderati, campagne di influenza. Se a questo si sommano dati personali e lavorativi, l’escalation di rischio è evidente. Anche senza un download massivo, bastano poche schede “giuste” nelle mani sbagliate per creare danni mirati.
La lezione si estende a qualunque contesto pubblico o sanitario: quando una piattaforma gestisce informazioni su milioni di cittadini, la protezione non può essere affidata alla buona sorte o a un fornitore lasciato solo. Servono standard, verifiche e accountability.
Cosa significa per Italia ed Europa
Piccoli fornitori, banche dati enormi
Anche da noi, una miriade di enti si appoggia a software house e agenzie che gestiscono servizi cruciali. Dalla sanità alla scuola, fino ai portali comunali e regionali, capita che player medio-piccoli tengano in mano patrimoni di dati giganteschi. Senza criteri stringenti su sicurezza, logging e risposta agli incidenti, la superficie d’attacco è enorme.
Compliance non basta: serve verifica tecnica
Avere policy, informative e tick di compliance non evita gli IDOR. Servono controlli tecnici concreti: code review, test di penetrazione periodici, bug bounty, segregazione dei dati, cifratura end-to-end dove possibile, gestione rigorosa delle chiavi, monitoraggio continuo con alert e piani di incident response provati sul campo.
Cosa possono fare le amministrazioni
- Alzare l’asticella negli appalti: requisiti di sicurezza misurabili (OWASP ASVS, test indipendenti, audit annuali), SLA per patch e incident response.
- Design sicuro by default: niente ID prevedibili, accesso strettamente autenticato, principle of least privilege, log a prova di manomissione.
- Verifica continua: pentest ricorrenti, controlli di terza parte, simulazioni di data breach e tabletop exercise.
- Gestione del ciclo di vita: patch rapide, inventario degli asset, deprovisioning degli ambienti legacy.
Cosa possiamo fare come cittadini
- Limitare la sovra-condivisione: nei moduli istituzionali inserire solo ciò che è richiesto, controllare due volte i campi facoltativi.
- Proteggere gli account: usare password manager e 2FA quando disponibile sui portali pubblici.
- Vigilare e segnalare: se un sito mostra dati altrui o ha comportamenti sospetti, evitare test “invasivi” e segnalare all’ente in modo responsabile.
- Chiedere trasparenza: pretendere logiche chiare su chi tratta i dati, dove risiedono e come vengono protetti.
Come si è chiusa (per ora) la vicenda
Dopo la segnalazione, il fornitore ha corretto la vulnerabilità e gli stati coinvolti hanno ricevuto conferma della risoluzione, come riportato da TechCrunch. È positivo, ma non basta a metterci tranquilli. Se un errore così elementare arriva in produzione e resta online per mesi o anni, la domanda è: quanti sistemi simili hanno lo stesso difetto e non lo sappiamo ancora?
La risposta pratica è una sola: smettere di trattare la sicurezza come adempimento burocratico o “opzione premium”. Nelle infrastrutture che toccano diritti, salute e giustizia, la sicurezza è parte del servizio, non un extra.
Il punto strategico: responsabilità condivisa
La tecnologia ci dà comodità e velocità, ma amplifica gli impatti degli errori. Servono tre cose, subito: responsabilità chiara (chi decide, chi verifica, chi risponde), competenze reali (non solo carte, ma test tecnici), e pressione pubblica. Perché la politica si muove quando i cittadini “rompono le scatole” al momento giusto, chiedendo portali sicuri quanto sono comodi.
👉 Per scoprire tutti i dettagli e l’opinione personale di Mario Moroni, ascolta la puntata completa su Spotify.