La sicurezza nelle applicazioni web: i fondamenti che nessuno può ignorare

Ogni applicazione web è, in pratica, una porta aperta sul mondo. Puoi scassinare la serratura o lasciare la chiave sotto il tappeto. La maggior parte dei team, senza rendersene conto, sceglie la seconda opzione, non per incompetenza, ma perché la sicurezza raramente viene considerata un requisito fin dall'inizio.

La domanda che faccio a qualsiasi squadra è semplice: se un attaccante decidesse di attaccarvi oggi, quanto tempo impiegherebbe? La risposta onesta è spesso scomoda. E il problema non è quasi mai la mancanza di tecnologia. È una mancanza di fondamento.

Questo articolo riguarda queste nozioni di base. Non sullo strumento alla moda, ma sui principi che sostengono un'applicazione web che merita fiducia.

Perché la sicurezza è diventata un problema aziendale

C'è stato un tempo in cui la sicurezza era un argomento limitato al team dell'infrastruttura. Oggi è un problema di amministratore delegato, consiglio di amministrazione e reputazione.

Una fuga di dati non è solo un bug. È un titolo, è una multa, è un cliente perso. In Brasile, la LGPD ha portato conseguenze concrete per coloro che trattano i dati personali in modo imprudente. Ma anche senza regolamentazione, il costo di un incidente è sempre stato elevato ed è solo diventato più visibile.

Il punto è che la sicurezza non è più un dettaglio tecnico ma è diventata una variabile aziendale. Coloro che guidano prodotti o tecnologia devono capirlo per decidere dove investire.

La tesi: la sicurezza è architettura, non vernice

La mia posizione è semplice. La sicurezza non è un livello che aggiungi dopo che il prodotto è pronto. È una proprietà che emerge dalle decisioni che prendi fin dall'inizio.

I team che trattano la sicurezza come un compito finale, una revisione prima del lancio, un test frettoloso, stanno solo comprando l’illusione della protezione. Il test della penna rileva i sintomi. L'architettura definisce se la malattia esiste.

Quando la sicurezza è fondamentale, appare nel modo in cui modelli i dati, nel modo in cui autentichi gli utenti, nel modo in cui ti fidi (o diffidi) dell'input. Quando è vernice, appare in un rapporto che nessuno legge.

I fondamenti che contano davvero

Sarò pragmatico. Esistono dozzine di argomenti possibili, ma alcuni concetti fondamentali risolvono la maggior parte dei problemi reali.

Non fidarti mai dell'input dell'utente

La maggior parte delle vulnerabilità classiche, SQL injection, cross-site scripting, manipolazione dei parametri, nascono dallo stesso errore: fidarsi dei dati che provengono dall’esterno.

La regola è semplice e non negoziabile: ogni ingresso è ostile fino a prova contraria. Convalida sul server, sempre. La convalida nel browser riguarda l'esperienza dell'utente, non la sicurezza, è banalmente aggirabile.

Utilizzare query con parametri nel database. Uscite di fuga in base al contesto. Tratta i caricamenti di file come codice potenzialmente dannoso. Queste precauzioni sembrano ovvie, ma continuano a essere causa di incidenti che fanno notizia.

Autenticazione e autorizzazione sono cose diverse

L'autenticazione risponde "chi sei". L'autorizzazione risponde "cosa puoi fare". Confondere i due è una ricetta per il disastro.

L'errore più comune che vedo: applicazioni che controllano se l'utente ha effettuato l'accesso, ma non controllano se ha l'autorizzazione per accedere a quella risorsa specifica. Il risultato è il classico problema in cui l'utente A può vedere i dati dell'utente B semplicemente modificando un numero nell'URL.

L'autorizzazione deve essere verificata sul server, su ogni richiesta sensibile, mai data per scontata in base a ciò che mostra l'interfaccia. Nascondere un pulsante non protegge nulla.

Gestisci i segreti come segreti

Password, chiavi API, token di accesso. Questi dati non appartengono al codice sorgente, non appartengono al repository e sicuramente non appartengono a un file di configurazione con versione.

Le password degli utenti devono essere archiviate con algoritmi di hashing progettati per questo scopo, non con crittografia reversibile e tanto meno in testo semplice. Utilizza librerie consolidate. La crittografia fatta in casa è uno dei modi più rapidi per creare un problema che non rileverai finché non sarà troppo tardi.

La crittografia in transito non è facoltativa

Tutto il traffico deve utilizzare HTTPS. Oggi non esiste alcuna giustificazione ragionevole per il contrario. I dati che viaggiano senza crittografia possono essere intercettati, comprese le credenziali.

Ma attenzione: HTTPS protegge il percorso, non la destinazione. Un'applicazione può avere un lucchetto verde nel browser e memorizzare comunque le password in formato testo normale. La crittografia in transito e quella a riposo sono livelli distinti ed entrambi sono importanti.

Cosa ci insegna OWASP

Quando qualcuno mi chiede da dove cominciare, la mia risposta è quasi sempre la stessa: iniziare con OWASP.

L'OWASP Top 10 è un elenco delle vulnerabilità più critiche nelle applicazioni web, gestito dalla comunità e aggiornato periodicamente. Non è uno standard burocratico, è una mappa delle minacce che effettivamente causano danni.

Il suo valore non sta nel memorizzare la lista, ma nell'usarla come linguaggio comune all'interno del team. Quando tutti capiscono cos'è un controllo degli accessi non funzionante o una configurazione di sicurezza non riuscita, le conversazioni tecniche diventano più obiettive e le decisioni diventano più informate.

Consiglio di inserire la Top 10 come parte del processo: una revisione leggera ma coerente che chieda "siamo esposti a qualcuno di questi rischi?" prima di ogni consegna rilevante.

Errori culturali che sabotano la sicurezza

La parte più difficile della sicurezza non è tecnica. È culturale.

Il primo errore è considerare la sicurezza come responsabilità di una persona o di un gruppo isolato. La sicurezza è responsabilità di chi scrive codice, di chi progetta prodotti e di chi dà priorità al backlog. Quando diventa il lavoro di qualcuno, non diventa il lavoro di nessuno.

Il secondo errore è il teatro della sicurezza: politiche estensive che nessuno segue, processi che esistono nel documento ma non su base quotidiana. La vera sicurezza è discreta e operativa, non un manuale in un cassetto.

Il terzo, e forse il più pericoloso, è la falsa sensazione che "a me non succederà". Le piccole applicazioni vengono attaccate continuamente, spesso dall'automazione che non sceglie un bersaglio. Essere piccoli non è protezione.

La sicurezza come vantaggio, non come costo

C'è un modo migliore per guardare tutto questo. Una sicurezza ben fatta non è solo difesa, fa la differenza.

Nei settori che trattano dati sensibili, come la sanità, la finanza e il settore pubblico, la fiducia è la valuta. Un prodotto che dimostra attenzione ai dati ottiene un vantaggio rispetto a un concorrente che tratta l’argomento con disprezzo. Per i manager pubblici, questo è ancora più critico: i dati dei cittadini non sono una risorsa dell’organizzazione, sono una responsabilità.

Investire nei fondamentali della sicurezza non ferma l’innovazione. Al contrario, ti dà una base solida su cui puoi costruire velocemente senza paura che tutto crolli.

La sicurezza non è ciò che fai quando hai tempo. È ciò che definisce se il prodotto che stai costruendo merita di esistere.

Se la tua organizzazione sta sviluppando applicazioni web e la sicurezza è ancora un argomento lasciato fino alla fine, vale la pena rivisitare questa priorità. Ho altri articoli sul blog su LGPD, crittografia e architettura sicura, e sono sempre aperto allo scambio di idee con chiunque prenda sul serio questo argomento.