La sicurezza backend è un tema che troppi team sottovalutano fino a quando non è troppo tardi. Dipendenze vecchie, configurazioni di sviluppo finite in produzione, secret messi ovunque come coriandoli: ecco come nasce un disastro, e come evitarlo anche se il tuo team non è formato da venti persone.
Parliamoci chiaro: se il tuo prodotto gira su un framework web moderno — Laravel, Django, Rails, Express, scegli tu — è molto probabile che il tuo server di produzione abbia dipendenze con vulnerabilità note. È una situazione più comune di quanto si pensi.
E la cosa peggiore? Probabilmente lo sapete già. Chi gestisce il tech pensa "prima o poi aggiorniamo tutto". Quel famoso task su Jira, "aggiornamento dipendenze", che ormai da sei mesi slitta di sprint in sprint. Nessuno lo mette mai tra le priorità, tanto non porta nessuna funzionalità visibile.
Poi arriva quel martedì mattina in cui ti arriva una email che ti informa che il tuo token è stato revocato in quanto apparso su un repo Github privato, e il "prima o poi" si trasforma di colpo in "doveva essere ieri".
Questo articolo è per chi deve prendere decisioni su un prodotto software. È una triste storia vista troppe volte. E il finale, spesso, è lo stesso.
Come si buca un server nel 2026
Lasciate stare l’immagine dell’hacker col cappuccio e la maschera di Guy Fawkes, lo schermo nero pieno di codice verde e il computer che fa bip-bip ogni volta che appare il testo. Gli attacchi di oggi sono spesso noiosi, metodici, e sfruttano la pigrizia di chi gestisce i server più che l’ingegno di chi li attacca.
Di solito funziona così.
Un framework web famoso ha una libreria che si installa di default o perché serve per una feature secondaria. Esce una CVE critica, cioè una vulnerabilità di sicurezza riconosciuta e catalogata pubblicamente, tipo la recente CVE-2025-54068, che permette a un attaccante di eseguire codice sul server con una richiesta ben costruita. Il fix spesso esce in tempi brevi, e aggiornare di solito basta.
Sei mesi dopo, capita di trovare server ancora sulla versione bucata.
L’attaccante non ha bisogno di essere un genio. L’exploit è pubblico, ci sono già gli script pronti. Scannerizza automaticamente migliaia di server, identifica versioni vulnerabili tramite fingerprinting e prova exploit già pronti. Spesso in tempi più rapidi di un vostro deploy, è già dentro.
Se riesce a eseguire codice o leggere file sul server, può accedere al file .env con tutte le variabili d’ambiente. Quel file è un tesoro per chi attacca: ci trova molto, dalle credenziali del database ai token API di GitHub, dalle chiavi AWS ai token del servizio di hosting, ai segreti OAuth. Informazioni critiche sulla tua infrastruttura possono trovarsi tutte concentrate in un unico file.
A quel punto diventa un disastro completo, ben oltre il "semplice incidente di sicurezza". Dovete cambiare tutte le credenziali esposte, controllare che non abbia installato backdoor, verificare che non abbia girato su altri server con i token rubati, avvisare chi va avvisato. Giorni di lavoro bruciati e la paranoia che qualcosa vi sia sfuggito.
Le tre vulnerabilità che vedo più spesso nei backend
I disastri, per quello che ho visto, nascono spesso da tre errori ricorrenti. Presi singolarmente, si gestiscono. Ma insieme diventano una vera e propria kill chain.
1. Debug attivo in produzione
Ogni framework ha la modalità debug, cioè la configurazione che mostra molti dettagli tecnici utili a chi sviluppa. Quando la lasci attiva, in caso di errore mostra stack trace dettagliati, variabili d’ambiente, percorsi del filesystem, a volte informazioni sensibili che aiutano molto un attaccante. Serve tantissimo in sviluppo. In produzione, è come lasciare le chiavi di casa infilate nella porta con un post-it sopra: "entrate pure".
E succede più spesso di quanto si voglia ammettere. Un deploy fatto di corsa, un copia-incolla sbagliato del file di configurazione, un "lo sistemo dopo" che resta lì per mesi. E spesso nessuno se ne accorge, il sito continua a funzionare uguale — la modalità debug può passare inosservata all’utente normale, ma fornire informazioni molto utili a chi attacca. Per dire, mi è capitato di trovare due deploy fatti così in una settimana (non sto romanzando ai fini del post, sono serio!). Prima di mettere in produzione, controlla tutto due volte!
2. Dipendenze fantasma
Alcuni pacchetti possono registrare automaticamente route, endpoint o middleware senza che tu debba scrivere una riga di codice. È uno degli effetti collaterali dei framework moderni: tutto funziona subito.
Il problema è che queste route possono finire in produzione e diventare pubbliche, e tu magari non te ne accorgi nemmeno perché non le hai scritte tu. Alcuni pacchetti possono esporre endpoint o funzionalità accessibili via web senza che tu li abbia scritti direttamente.
Quante route ha davvero il tuo server di produzione? Se pensi "quelle che abbiamo scritto noi", probabilmente ti sbagli. Fatevi un audit!
3. I segreti nello stesso cestino
Il file .env è una comodità che ti si può ritorcere contro. Un unico file con dentro tutte le chiavi: database, cloud, API, servizi di deploy, OAuth. Se qualcuno mette le mani su quel file, può potenzialmente accedere a gran parte della tua infrastruttura. Se lì dentro c’è il token del tuo hosting, l’attaccante può entrare in più punti: leggere le variabili degli altri progetti, aggiungere SSH key, cambiare gli script di deploy, piazzare backdoor che possono resistere anche a pulizie superficiali.
Può bastare un solo file compromesso e, come niente, l’attaccante si trova la strada molto più aperta verso tutta l’infrastruttura. Se il server è già stato bucato, puoi ragionevolmente temere che quel file ora sia in mani sbagliate.
Perché la sicurezza viene sempre dopo
Arriviamo al punto dolente.
Tutti e tre gli errori di cui ho parlato si risolvono in modo relativamente banale. Disattivare il debug può richiedere una sola configurazione. Aggiornare una dipendenza può essere questione di un comando. Vault per i segreti? Esiste già, e in molti casi basta integrarlo.
Il problema? Spesso non c'è tempo, mandato o voglia di farlo.
Chi guida il tech ha almeno altre 15 priorità. Il team corre per consegnare la feature che il cliente aspetta da mesi. Nessuno metterà “aggiornamento librerie” in cima al backlog: non si vede, non si vende, non fa scena in demo.
La sicurezza è uno degli ambiti dell'ingegneria dove non fare nulla sembra andare benissimo — fino al giorno in cui tutto esplode, tutto insieme. È un po' come i costi di manutenzione del software: invisibili finché non ti presentano il conto.
È come l’assicurazione sulla casa: è una spesa inutile. Finché non viene un alluvione.
Cosa fare davvero (anche senza un team dedicato)
Non ti serve un esercito. Bastano poche pratiche ben impostate che, una volta messe in piedi, continuano a lavorare da sole.
La prima è un gate automatico nella pipeline di deploy, cioè nella sequenza di controlli e passaggi che porta il codice in produzione. Prima di ogni rilascio deve esserci un controllo che faccia almeno due cose: verificare che non esistano CVE gravi note nelle dipendenze e controllare che le configurazioni sensibili siano corrette. Se qualcosa non va, il deploy si ferma. Se avete già una CI/CD, cioè un sistema che automatizza test e rilasci, aggiungere un composer audit o un npm audit può portarvi via poco tempo; se partite da zero servono alcuni giorni per farlo bene, ma poi quel controllo continua a lavorare in modo costante.
La seconda pratica è un audit mensile molto semplice. Non serve per forza un penetration test da migliaia di euro. Spesso basta dedicare mezz’ora al mese a lanciare composer audit o l’equivalente, controllare gli endpoint realmente esposti in produzione, verificare che debug ed error reporting siano configurati correttamente e attivare strumenti come Dependabot su GitHub. È un controllo leggero, ma evita molti problemi grossi.
La terza riguarda i secret. Tenerli tutti in un file di testo è comodo, ma non è una soluzione matura per la produzione. Meglio usare strumenti come AWS Secrets Manager e, quando possibile, attivare una rotazione automatica. Se un secret viene rubato ma cambia ogni trenta giorni, l’attaccante ha una finestra molto più stretta per fare danni. Se invece resta nello stesso .env per due anni, il rischio cresce enormemente.
Il discorso scomodo per chi decide
Se sei arrivato fin qui e prendi decisioni sul prodotto, questa parte è per te.
Ogni sprint in cui rimandi la manutenzione di sicurezza, stai facendo debiti. Non è debito tecnico vago: sono interessi veri, in giorni persi a rimediare, costi legali se ci scappano dati personali, danni alla reputazione, e quella settimana in cui il team migliore non fa feature ma corre a ruotare chiavi e a cercare backdoor. E se pensi di risolvere aggiungendo più sviluppatori alla gestione di una crisi in corso, il risultato è spesso l'opposto di quello sperato.
Il conto è abbastanza chiaro. Qualche giorno per impostare i controlli automatici, mezz’ora al mese per un audit. Dall’altra parte, una settimana di lavoro buttata per un incidente, più i soldi della notifica GDPR, più il danno d’immagine.
Non è solo "se" succede. Spesso è "quando". E quel quando dipende anche da quanto è sveglio chi ti sta scannerizzando.
Incident response: cosa fare quando ti hanno bucato
Se sei qui perché il problema è già esploso, la prima cosa da fare è revocare tutto subito. Ogni token, ogni API key, ogni credenziale che era nel file .env va considerata compromessa. Non “appena riesci”: adesso.
Subito dopo vanno cambiate tutte le password e le credenziali dei servizi collegati. Se nel file c’erano token di Forge, DigitalOcean, Hetzner o servizi simili, devi partire dal presupposto che qualcuno possa già muoversi sui tuoi server. Guarda i log di accesso e controlla ogni servizio collegato.
Poi bisogna cercare le backdoor. Controlla cron job, chiavi SSH autorizzate, file modificati di recente. Chi entra in un sistema spesso prova a lasciarsi una strada aperta per tornare. E non fidarti mai della sensazione che “sembra tutto ok”: se non trovi niente, può semplicemente voler dire che non l’hai ancora trovato.
Infine scrivi tutto. Segna orari, azioni eseguite e ciò che hai scoperto. Ti servirà sia per ricostruire l’incidente sia, se ci sono dati personali coinvolti, per tutto ciò che riguarda la GDPR.
La prima reazione è mettere tutto a posto in fretta e poi far finta di niente. Ma resisti. Se fai le cose bene ora, eviti di ripetere lo stesso incubo tra tre mesi.
Il tuo backend non è una bomba a orologeria per colpa di come l’hanno progettato. Diventa davvero pericoloso soprattutto se lo trascuri. E oggi, nel 2026, puoi automatizzare quasi tutta la fatica della manutenzione.
Simone Giusti
Consulente software strategico
