Piattaforme web e data breach, la privacy by design non può essere solo teoria

• Primo Piano
• Giovedì, 12 Febbraio 2026 15:54

Le soluzioni software web based sono oggi strumenti imprescindibili per aziende, professionisti e pubbliche amministrazioni. Gestionali, piattaforme documentali, portali con aree riservate: applicazioni raggiungibili da qualsiasi luogo, in qualsiasi momento, da qualsiasi dispositivo. Un vantaggio enorme, che porta con sé responsabilità significative per le aziende pubbliche e private sul piano della protezione dei dati personali.

Infatti, agli articoli 25 e 32, il GDPR impone che la protezione dei dati sia integrata fin dalla progettazione (privacy by design) e che le impostazioni predefinite garantiscano il massimo livello di tutela (privacy by default). Principi chiari nella teoria, che nella pratica trovano però ancora un’applicazione parziale.

La casa con le finestre aperte – Sempre più spesso, clamorosi data breach che finiscono sotto i riflettori delle notizie di cronaca, come quello in cui migliaia di documenti d’identità di clienti di hotel sono stati trafugati e messi in vendita nel Dark Web, o quello più recente scoperto da Fanpage in cui migliaia di carte d’identità e altri documenti conservati su una piattaforma utilizzata dalle scuole sono stati trovati liberamente accessibili online e addirittura indicizzati sui motori di ricerca, ci ricordano che una piattaforma web è come una casa con porte e finestre spalancate.

Ogni URL, ogni risorsa su un server è potenzialmente accessibile a chiunque abbia una connessione internet. Dietro a ciascun punto di ingresso deve esserci una “guardia” che verifichi le credenziali. Ma se anche una sola finestra resta sguarnita, chiunque può entrare, da qualsiasi parte del pianeta e magari senza lasciare traccia. Rispetto a un software installato su rete locale, una soluzione web ha una superficie esposta a potenziali attacchi informatici enormemente più estesa.

Il punto di partenza: la valutazione d’impatto privacy - Prima di scrivere una riga di codice, lo sviluppo di una piattaforma web dovrebbe partire da una valutazione d’impatto sulla protezione dei dati. A quale scopo è destinato il software? Quali dati personali saranno trattati? Chi vi avrà accesso e con quali livelli di autorizzazione? Sono domande che determinano l’intera architettura: dalla struttura del database alla gestione dei file, dalle policy di accesso alle misure di sicurezza.

Un gestionale sanitario richiede misure radicalmente diverse da un portale turistico. Senza questa analisi, il rischio è costruire un software funzionante ma inadeguato, con costi di adeguamento successivi enormemente superiori a quelli di una progettazione corretta.

Le minacce specifiche dell’ambiente web - Una piattaforma web è esposta a minacce che un software locale non conosce. Bot, spider e crawler scandagliano la rete cercando contenuti indicizzabili e vulnerabilità sfruttabili. Se le aree riservate non sono protette, i loro contenuti possono finire nei motori di ricerca. L’uso delle direttive noindex e nofollow nei meta tag e nel robots.txt è una prima barriera, ma non sufficiente: i motori di ricerca “per bene” le rispettano, un bot malevolo le ignora completamente.

Si aggiungono poi le minacce dirette all’integrità dei dati, come gli attacchi SQL injection, attraverso i quali un aggressore manipola le query al database inserendo codice malevolo nei campi di input. Prevenirli richiede query parametrizzate, validazione rigorosa dei dati in ingresso e applicazione del principio del privilegio minimo sugli accessi al database.

I file fuori dal database: la vulnerabilità nascosta - Documenti Word, fogli Excel, PDF, immagini: in moltissime piattaforme gestionali questi file vengono salvati in cartelle del server e nel database viene registrato solo il percorso. Il problema sorge quando quelle cartelle, per una errata valutazione in fase di progettazione del software, risultano raggiungibili via browser, senza controllo di autenticazione. Chiunque conosca la struttura delle directory può accedere a documenti riservati. La protezione non può limitarsi al database: i file devono poter essere accessibili solo tramite script server-side che verifichino la sessione utente, va impedito il listing delle directory e vanno adottati nomi per cartelle e file che non siano prevedibili.

(Nella foto: Michele Caccialupi, Consulente informatico)

Il ruolo del DPO: verificare, non solo documentare – Nell’era digitale in cui viviamo, il Data Protection Officer non può limitarsi alla conformità burocratica. Registri compilati, informative pubblicate e nomine formalizzate sono condizioni necessarie, ma non sufficienti. La domanda chiave è: le soluzioni software adottate sono realmente adeguate allo scopo? Il software gestisce solo i dati strettamente necessari? I meccanismi di protezione sono proporzionati alla natura dei dati trattati? Rispondere richiede competenze tecniche specifiche.

Il DPO deve quindi promuovere audit periodici coinvolgendo specialisti capaci di verificare l’effettiva robustezza delle soluzioni: dalla protezione dei file alla resistenza agli attacchi injection, dalla configurazione dei meta tag alla gestione delle sessioni. Ogni aggiornamento può introdurre nuove vulnerabilità: la sicurezza è un processo, non uno stato.

Conclusione - Sviluppare piattaforme web conformi al GDPR richiede un approccio integrato che parta dalla valutazione d’impatto e accompagni il software per tutto il suo ciclo di vita. La privacy by design non è un principio astratto da dichiarare in un documento o in una policy: è un requisito concreto che deve trovare riscontro in ogni riga di codice, in ogni configurazione del server e in ogni verifica condotta dal Data Protection Officer, che non può limitarsi ad essere un burocrate conoscitore sopraffino della normativa, ma deve possedere anche competenze trasversali in materia di cybersecurity, avvalendosi di esperti di della materia che possano affiancarlo quando i dati personali sono gestiti attraverso piattaforme web based.