Come mettere in sicurezza la tua web app

La sicurezza è facile da considerare un problema di qualcun altro, finché un incidente non la trasforma nel proprio. La buona notizia è che la grande maggioranza delle violazioni reali non deriva da zero-day esotici, ma da un insieme ristretto di errori ben noti. Non è necessario essere un ricercatore di sicurezza per correggerli. Serve una baseline, applicata con costanza. Ecco quella che ogni web app dovrebbe avere.

Gestire correttamente autenticazione e sessioni

L'autenticazione è il punto da cui originano la maggior parte dei fallimenti gravi: non reinventate la ruota. Utilizzate una libreria o un provider consolidato anziché implementare da zero l'hashing delle password e la logica di sessione.

• Hashate le password con un algoritmo moderno come bcrypt o argon2; non conservatele mai in forma reversibile.
• Gestite le sessioni in modo sicuro: token a breve scadenza, cookie con flag secure e HttpOnly, e un logout che invalidi davvero la sessione.
• Verificate le autorizzazioni lato server, ogni volta. Nascondere un pulsante nell'interfaccia non è un controllo di accesso. Verificate i permessi nel backend per ogni richiesta e adottate il principio di negazione predefinita.

Il broken access control — un utente che accede a dati o azioni a cui non dovrebbe — è costantemente tra le vulnerabilità web più diffuse e dannose.

Trattare ogni input come ostile

Qualsiasi dato proveniente da un client è un potenziale vettore di attacco. Due categorie classiche continuano a dominare:

1. Injection. Utilizzate sempre query parametrizzate o un ORM; non costruite mai SQL concatenando stringhe. Questo elimina alla radice l'SQL injection.
2. Cross-site scripting (XSS). Escapate e sanificate qualsiasi contenuto fornito dall'utente prima di renderizzarlo. I framework moderni aiutano, ma dangerouslySetInnerHTML e i suoi equivalenti vi si ritorcono contro.

Validate gli input lato server rispetto a uno schema rigoroso. La validazione lato client serve all'esperienza utente, non è un controllo di sicurezza: chiunque può aggirarla.

Proteggere segreti e configurazione

Le credenziali nel codice sorgente sono una violazione in attesa di essere indicizzata. Tenete i segreti completamente fuori dal controllo versione: utilizzate variabili d'ambiente o un secrets manager e ruotateli se dovessero trapelare. Analizzate la cronologia del repository, non solo i file attuali: una chiave committata una volta rimane nella history per sempre.

Distribuire header sicuri e HTTPS

Alcune impostazioni predefinite a basso costo alzano sensibilmente il livello di protezione:

• HTTPS ovunque, con HSTS affinché i browser rifiutino il downgrade.
• Header di sicurezza: una Content-Security-Policy per attenuare gli XSS, oltre a X-Content-Type-Options e protezioni contro il framing.
• Protezione CSRF per le sessioni basate su cookie, tramite anti-CSRF token.
• Rate limiting sugli endpoint di autenticazione e su quelli sensibili, per rallentare i tentativi di brute-force.

Mantenere le dipendenze sotto controllo

Le applicazioni moderne sono per lo più codice scritto da altri, e le vulnerabilità in quel codice diventano vostre. Eseguite scansioni automatiche delle dipendenze in CI, mantenete i pacchetti ragionevolmente aggiornati e siate selettivi su ciò che aggiungete: ogni dipendenza è superficie d'attacco. Una libreria vulnerabile dimenticata è uno dei vettori di accesso più comuni.

Farne un'abitudine, non un evento

La sicurezza non è una checklist da spuntare una volta prima del lancio: è una postura da mantenere nel tempo. Integrate queste pratiche nel vostro flusso di lavoro: query parametrizzate per impostazione predefinita, segreti mai committati, scansioni delle dipendenze nella pipeline e controlli di autorizzazione su ogni endpoint. Applicate le basi con costanza e sarete davanti alla maggioranza delle applicazioni, fuori dalla portata degli attacchi opportunistici che causano la maggior parte dei danni.

Se volete una revisione della sicurezza prima di rilasciare qualcosa di importante, contattateci.