Esiste un'idea diffusa secondo cui gli attacchi informatici riguardino solo le grandi aziende — quelle con migliaia di dipendenti, infrastrutture complesse, dati di valore strategico. È un'idea comoda, ma sbagliata. Le PMI sono spesso bersagli più attraenti proprio perché si difendono meno: sistemi non aggiornati, password condivise, nessun piano di risposta agli incidenti. Non si tratta di sfortuna — si tratta di un rischio calcolabile e, soprattutto, prevenibile.
Non occorre un team dedicato alla cybersecurity per costruire un'applicazione web sicura. Occorre prendere alcune decisioni giuste fin dall'inizio — perché correggere le vulnerabilità dopo il lancio costa sempre di più che prevenirle in fase di sviluppo.
Le vulnerabilità più comuni nelle applicazioni web
Iniezioni SQL. È una delle vulnerabilità più vecchie e ancora tra le più frequenti. Accade quando un'applicazione inserisce direttamente l'input dell'utente in una query al database senza sanificarlo. Un attaccante può così manipolare la query e ottenere accesso a dati che non gli appartengono — o cancellare l'intero database. La protezione è relativamente semplice: usare query parametrizzate e non concatenare mai stringhe di input direttamente nelle query.
Autenticazione debole. Password senza requisiti minimi, sessioni che non scadono mai, mancanza di autenticazione a due fattori per accessi sensibili. Ogni account con una password debole è una porta aperta. Oggi non c'è motivo per non implementare standard moderni di autenticazione fin dalla prima versione.
Esposizione di dati sensibili. Dati personali, credenziali, informazioni finanziarie trasmessi senza cifratura, o memorizzati in chiaro nel database. Il principio base è semplice: i dati sensibili devono essere cifrati sia in transito (HTTPS obbligatorio) sia a riposo. Le password, in particolare, non vanno mai memorizzate — nemmeno cifrate — ma trasformate con algoritmi di hashing sicuri e irreversibili.
La regola più importante: non fidarti mai dell'input che arriva dall'esterno. Qualsiasi dato proveniente da un utente — un modulo, un parametro URL, un file caricato — va considerato potenzialmente ostile fino a prova contraria. Validare e sanificare tutto l'input è la base di qualsiasi applicazione sicura.
Il principio del minimo privilegio
Ogni utente del sistema — che sia un dipendente, un cliente o un processo automatizzato — dovrebbe avere accesso solo alle risorse strettamente necessarie per svolgere il proprio compito. Un venditore non ha bisogno di vedere i dati di pagamento. Un operatore di magazzino non ha bisogno di accedere ai report finanziari. Un servizio di invio email non ha bisogno di scrivere sul database.
Questo principio sembra ovvio, ma viene violato sorprendentemente spesso — per comodità, per fretta, o perché nessuno ha mai pensato a definire i ruoli in modo esplicito. Progettare i permessi correttamente fin dall'inizio limita drasticamente il danno in caso di compromissione di un singolo account.
Backup e recovery: il piano che nessuno vuole scrivere
I backup sono la rete di sicurezza che protegge da tutto il resto: attacchi ransomware, errori umani, guasti hardware, bug che corrompono i dati. Eppure sono spesso il primo aspetto trascurato nella pianificazione di un'applicazione.
Un piano di backup efficace definisce tre cose: con quale frequenza vengono eseguiti i backup, dove vengono conservati (mai sullo stesso server dell'applicazione), e quanto tempo ci vuole per ripristinare il sistema in caso di emergenza. Quest'ultimo punto è quello che si scopre solo quando il disastro è già accaduto — meglio simularlo prima.
GDPR e dati personali nelle applicazioni
In Europa, raccogliere e trattare dati personali comporta obblighi precisi. Non si tratta solo di mostrare un banner cookie: occorre documentare quali dati si raccolgono, per quale scopo, per quanto tempo si conservano e come vengono protetti. Ogni applicazione che vuole gestire dati in un sistema centralizzato e sicuro ricade nel perimetro del GDPR.
Le conseguenze di una violazione — sia tecnica che normativa — possono essere significative. Ma la buona notizia è che progettare un'applicazione conforme al GDPR e progettare un'applicazione sicura sono la stessa cosa: entrambe richiedono di raccogliere solo i dati necessari, proteggerli adeguatamente e sapere sempre dove si trovano.
Sicurezza by design: perché è più economica
Aggiungere sicurezza a un sistema già costruito è difficile, costoso e spesso incompleto. Le vulnerabilità sono spesso strutturali — radicate nell'architettura, non nella superficie. Rimediarle in seguito significa spesso riscrivere parti significative del codice.
Progettare la sicurezza fin dall'inizio, invece, ha un costo marginale: si tratta di includere i requisiti di sicurezza nel brief, scegliere le librerie giuste, impostare le configurazioni corrette, definire i permessi fin dal primo sprint. Il costo è minimo. Il valore — in termini di rischio evitato — è enorme.