All’inizio del 2026 è circolata la notizia secondo cui dei criminal hacker avrebbero sottratto i dati di 17,5 milioni di account Instagram, versione dei fatti che Meta ha respinto con fermezza: non si è trattato di hacking nel senso tradizionale del termine. Non si è trattato di hacking ma di scraping.
Infatti, nessun server o database è stato violato e nessun firewall ha ceduto sotto il peso degli attacchi esterni. Il risultato però apre un fronte chiaroscuro perché, a febbraio, i dati degli utenti coinvolti erano reperibili sul dark web.
Una vicenda utile a riaccendere le luci sull’hacking e sullo scraping per capire come aziende e individui possono difendersi quando le vulnerabilità sono intrinseche alle logiche del business.
Nel caso specifico, mediando le tante ricostruzioni che sono state fatte da Meta e da esperti del settore, la spiegazione più logica e accreditata riconduce a una massiccia raccolta di dati probabilmente risalente al 2024, effettuata mediante API ed endpoint mal configurati e redistribuita poi nel 2026.
Indice degli argomenti
Le vulnerabilità API tra hacking e scraping
La distinzione tecnica tra hacking e scraping c’è, ma è sempre più sfumata.
Stando alle rispettive definizioni, l’hacking implica la violazione di sistemi attraverso lo sfruttamento di vulnerabilità tecniche per accedere a dati che dovrebbero essere protetti.
Lo scraping, invece, è tecnicamente la raccolta automatizzata di dati pubblici o accessibili tramite interfacce legittime, come le API o le pagine web.
Nel caso di Instagram e di altre piattaforme, la realtà si colloca in una zona grigia. I dati non sono stati estratti violando la crittografia o rubando credenziali di amministratore, gli attaccanti hanno sfruttato una vulnerabilità nella logica di business delle API aggirando i rate limit (i limiti di frequenza delle richieste) e utilizzato endpoint pubblici in modi non previsti dai progettisti del sistema, accumulando progressivamente milioni di record.
Per Akamai Tecnologies, azienda che gestisce una rete globale per la distribuzione e la protezione del traffico web, questi scenari sono abusi delle logiche di business, nella misura in cui l’uso di funzionalità API legittime sono impiegate per scopi non autorizzati, sfruttando lacune nei controlli di accesso o nella validazione delle richieste.
Dal canto suo, l’azienda di cyber security Check Point Software sottolinea che gli attacchi API moderni non sempre richiedono exploit tecnici classici, ma spesso si basano sull’abuso di comportamenti attesi del sistema.
Una differenza formale ma non sostanziale
Nel sostenere con fermezza che Instagram non ha subito violazioni, Meta non dice il falso ma imbocca una scorciatoia retorica che non giova a nessuno, tanto meno agli utenti.
Come fa notare il sito SecurityWeek (peraltro con un articolo pubblicato nel 2022) anche se lo scraping di dati pubblici non costituisce una qualsivoglia forma di hacking, le conseguenze in termini di esposizione dei dati sono identiche. Messaggio chiaro e condivisibile che Meta (e altre aziende) hanno preferito non recepire.
La differenza tra hacking e scraping ha senso se il danno è lo stesso?
La distinzione c’è, ovviamente, ma non dal punto di vista della gestione del rischio. Infatti, il funzionario ICT e membro Clusit Salvatore Lombardo evidenzia come “La distinzione tra hacking e scraping è rilevante per aspetti tecnici, legali e di responsabilità.
Mentre l’hacking implica una violazione dei sistemi, lo scraping sfrutta dati accessibili, spesso abusando delle funzionalità ma senza forzare alcun accesso. Tuttavia, l’effetto concreto sugli utenti, come nel caso Instagram, potrebbe essere lo stesso a causa di utilizzi indesiderati dei dati con la conseguente esposizione a truffe”.
Quando 17,5 milioni di utenti vedono i propri numeri di telefono, indirizzi email e dati di profilo esposti sul dark web, non importa se l’attaccante ha usato un exploit zero-day o un bot appositamente configurato.
Il danno e le conseguenze dello scraping si sovrappongono a quelle dell’hacking, richiamando il rischio di phishing mirato, il credential stuffing e persino i furti di identità.
La differenza tra hacking e scraping diventa quindi un dettaglio tecnico che non mitiga il rischio reale.
La natura culturale del problema
Molte aziende continuano a considerare lo scraping come un “fastidio operativo” piuttosto che una vera minaccia alla sicurezza. Questa mentalità spinge a investire massicciamente in firewall e sistemi di rilevamento delle intrusioni, mentre le protezioni contro l’abuso delle API sono spesso inadeguate o assenti.
Più che cercare distinzioni accademiche tra hacking e scraping come se il primo fosse colpa dell’azienda che subisce una violazione e lo scraping fosse una stortura endemica di tutto ciò che è esposto in rete, le organizzazioni dovrebbero chiedersi se stanno proteggendo i dati in modo adeguato.
L’intervento della NIS2
La direttiva Network and Information Security 2 (NIS2) non disciplina il data scraping in quanto tale e ciò può non essere d’aiuto agli utenti interessati. “La direttiva NIS2 – continua Salvatore Lombardo – non disciplina esplicitamente il data scraping in quanto adotta in generale un approccio neutro, cioè non legato a una specifica tecnica di attacco, lasciando ampio margine interpretativo nelle pratiche operative e difensive (ciò anche per evitare che la norma diventi obsoleta nel giro di pochi anni e per includere nuove tecniche senza aggiornamenti continui).
Tuttavia, senza indicazioni specifiche, collocandosi in una zona grigia (non è una violazione evidente, ma può generare impatti equivalenti a un data breach) per l’attività di scraping può esserci una gestione del rischio non uniforme tra le organizzazioni”.
Difendersi dal datascraping
La difesa contro lo scraping richiede un approccio stratificato, poiché non esiste una soluzione universale. Le strategie devono differenziarsi tra utenti singoli e organizzazioni.
Le aziende e chi gestisce piattaforme online dovrebbero miscelare accorgimenti tecnici e strategie organizzative.
Implementare limiti di frequenza basati sui comportamenti degli utenti al posto di impostare soglie fisse, ovvero prediligere tecniche di rate limiting avanzate.
Tra le attività da inserire nelle best practice devono trovare posto anche l’adozione di soluzioni che esaminano il comportamento delle richieste per distinguere gli utenti umani dai bot, insieme all’attitudine di testare con periodicità le API per identificarne le vulnerabilità.
In aggiunta, va presa in considerazione l’adozione di gateway API con Web Application Firewall (WAF) che – pure non essendo panacee – aiutano a rilevare e bloccare i pattern di scraping conosciuti.
Sul piano delle strategie organizzative, oltre al sempiterno monitoraggio continuo che segnala picchi di richieste e altre anomalie, ha senso adottare il principio del minimo privilegio ed esporre tramite API solo i dati strettamente necessari alle funzionalità richieste.
Inoltre, e questo vale per qualsiasi minaccia o emergenza, occorre avere procedure utili a limitare l’esposizione quando viene rilevato lo scraping.
I singoli individui, dal canto loro, hanno meno mezzi a disposizione perché sono le piattaforme a cui si iscrivono ad avere il pieno controllo dei dati.
Qualche freccia nella faretra, tuttavia, l’hanno anche le persone: tra queste la capacità di resistere alla pubblicazione compulsiva di dati personali. Dovrebbe sempre valere la regola “meno dati personali si pubblicano, meno si rischia”.
Il ricorso a indirizzi email creati appositamente per social media e quindi diversi da quelli usati per servizi online più essenziali è una buona regola, così come lo è – di tanto in tanto – fare uso di risorse quali Have i Been Pwned per verificare se i propri dati compaiono in nuove violazioni.
Infine, impostare laddove possibile l’ autenticazione a due fattori che, ovviamente, non previene lo scraping ma lenisce gli effetti causati da credenziali eventualmente trapelate.
