Hai fatto sviluppare un gestionale custom. Costa stato un investimento importante, il software funziona, il team lo usa ogni giorno. Ma quando qualcuno ti chiede "è sicuro?", la risposta onesta è: non lo sai con certezza.
Questa è la situazione reale della maggior parte delle PMI italiane con software custom in produzione. La sicurezza applicazioni web custom viene trattata come un problema da affrontare "quando si ha tempo" — che nella pratica significa mai, finché non succede qualcosa.
Questa guida è una checklist operativa per CTO e IT manager che vogliono capire dove sono esposti, in quale ordine intervenire e cosa delegare a specialisti esterni.
Quando usi Salesforce o HubSpot, la sicurezza è un problema del vendor. Loro gestiscono le patch, i certificati, gli aggiornamenti delle dipendenze. Tu paghi anche per questo.
Con un'applicazione custom, quella responsabilità ricade interamente su di te — o sul team che l'ha sviluppata.
Il punto critico è che molte applicazioni custom vengono rilasciate, testate funzionalmente, e poi lasciate girare per mesi o anni senza che nessuno aggiorni le librerie, riveda le configurazioni o faccia un audit del codice. Le dipendenze invecchiano. Le vulnerabilità note si accumulano nel composer.lock o nel package.json senza che nessuno le veda.
Un'applicazione Laravel con dipendenze non aggiornate da 18 mesi ha quasi certamente CVE (Common Vulnerabilities and Exposures) aperti. Non è un'ipotesi: è una certezza statistica.
La OWASP Top 10 è la lista dei vettori di attacco più comuni sulle applicazioni web. Non è pensata per i grandi gruppi: è uno standard di riferimento pratico, usabile anche da chi non ha un team di sicurezza dedicato.
Le voci che colpiscono più spesso le applicazioni custom italiane sono tre.
Injection (A03) — SQL injection, command injection, LDAP injection. Se il codice costruisce query concatenando input utente senza parametrizzazione, il rischio è alto. Nei framework moderni come Laravel il problema è quasi eliminato se si usano gli Eloquent model e i prepared statement. Il rischio torna quando qualcuno scrive query raw per "fare prima".
Security Misconfiguration (A05) — Credenziali di default, directory listing abilitato, file .env esposto, debug mode attivo in produzione. Questi errori non richiedono attacchi sofisticati: bastano pochi minuti di ricognizione con strumenti automatici.
Vulnerable and Outdated Components (A06) — Dipendenze con vulnerabilità note. È il problema silenzioso per eccellenza: non si vede, non rallenta l'applicazione, non genera errori. Si manifesta quando qualcuno la sfrutta.
Per ciascuna di queste voci, la prima domanda da farti è semplice: hai un processo attivo per monitorarla, o ti affidi alla fortuna?
Non tutto ha la stessa urgenza. Questa checklist è ordinata per impatto/sforzo.
| Area | Controllo | Priorità | Chi lo fa |
|---|---|---|---|
| Dipendenze | Audit CVE con composer audit / npm audit | Alta | Dev team |
| Configurazione server | Header HTTP di sicurezza (CSP, HSTS, X-Frame-Options) | Alta | Dev/DevOps |
| Autenticazione | MFA abilitato, password policy, session timeout | Alta | Dev team |
| Gestione segreti | Nessuna credenziale in chiaro nel codice o in repository | Alta | Dev team |
| Logging | Log di accesso e anomalie centralizzati, retention definita | Media | DevOps |
| Backup | Backup automatico testato (restore verificato, non solo eseguito) | Media | DevOps |
| Penetration test | Test esterno da specialista indipendente | Media | Terza parte |
| GDPR | Mappatura dati personali trattati, gestione consensi, diritto all'oblio | Media | DPO + Dev |
| Code review sicurezza | Revisione mirata su aree critiche (auth, upload, query) | Media | Dev senior / esterno |
| Hardening OS/web server | Porte aperte, servizi attivi, permessi filesystem | Bassa-Media | DevOps |
Parti dall'audit delle dipendenze: richiede meno di un'ora e ti dà subito un quadro concreto. Poi passa alla configurazione del server, che è spesso la fonte dei problemi più banali e più gravi insieme.
Il GDPR non è solo un problema del DPO. Se il software tratta dati personali — e quasi sempre lo fa, anche solo con i log di accesso degli utenti — il codice custom deve rispettare alcuni requisiti tecnici precisi.
Privacy by design significa che le scelte architetturali devono limitare la raccolta e la conservazione dei dati al minimo necessario. Se il tuo gestionale salva ogni click dell'utente per "analisi future", stai probabilmente raccogliendo più di quanto ti serva e più di quanto il GDPR ti permetta senza una base giuridica chiara.
Diritto all'oblio: il software deve essere in grado di eliminare tutti i dati riferibili a una persona fisica su richiesta. Sembra ovvio, ma in molte applicazioni custom i dati sono distribuiti tra tabelle diverse, log, backup e sistemi di terze parti integrati. Implementare il diritto all'oblio in modo completo richiede una mappatura precisa di dove ogni dato finisce.
Questo è un caso in cui la soluzione tecnica e quella legale devono lavorare insieme fin dalla fase di design, non aggiunte dopo.
Qui prendiamo una posizione netta: il penetration test è spesso venduto come una soluzione completa alla sicurezza, quando in realtà è uno strumento diagnostico. Se fai un pen test su un'applicazione con dipendenze non aggiornate e configurazione di default, ti ritrovi un report da 40 pagine che ti dice cose che avresti potuto scoprire in un'ora con composer audit e un security header checker gratuito.
Il pen test ha senso quando hai già fatto il lavoro di base — hardening, aggiornamento dipendenze, revisione del codice critico — e vuoi verificare che non ci siano vulnerabilità logiche o di business logic che gli strumenti automatici non trovano. Quelle richiedono un occhio umano esperto.
Per un'applicazione esposta a utenti esterni o che gestisce dati sensibili, un pen test annuale è una pratica corretta. Per un gestionale interno con pochi utenti e rete isolata, puoi partire da un audit interno ben fatto e rimandare il pen test al momento in cui l'applicazione cresce.
Hardening non significa blindare tutto. Significa ridurre la superficie di attacco togliendo quello che non serve e configurando correttamente quello che resta.
Tre interventi con il rapporto sforzo/beneficio più alto:
Primo: gli header HTTP di sicurezza. Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options. Configurarli correttamente richiede qualche ora, protegge da categorie intere di attacchi (XSS, clickjacking, MIME sniffing) e si verifica in trenta secondi con securityheaders.com. Molte applicazioni in produzione non li hanno.
Secondo: la gestione dei segreti. Nessuna credenziale nel codice, nessuna nel repository (neanche in quello privato). Le variabili d'ambiente devono essere gestite con un sistema dedicato (HashiCorp Vault, AWS Secrets Manager, o almeno un .env mai versionato). Se trovi credenziali nel repository, considera che chiunque abbia mai avuto accesso al repo le conosce — anche se le hai cambiate dopo.
Terzo: i permessi filesystem. L'applicazione deve girare con un utente di sistema dedicato, con i permessi minimi necessari. La cartella di upload non deve essere eseguibile. La directory di configurazione non deve essere leggibile dal web server. Questi errori sono banali ma frequenti.
Se stai valutando un'analisi della postura di sicurezza della tua applicazione, scrivici e vediamo insieme da dove partire.
Fare un audit di sicurezza una volta e poi dimenticarselo è quasi peggio che non farlo: ti dà una falsa sensazione di controllo.
Le vulnerabilità nascono nel tempo. Una libreria sicura oggi può avere un CVE critico domani. Una configurazione corretta può diventare problematica dopo un aggiornamento del sistema operativo. Un nuovo sviluppatore può introdurre un pattern insicuro senza accorgersene.
Quello che serve è un processo minimo ma continuo:
Non è un carico insostenibile. È la differenza tra scoprire un problema in anticipo o scoprirlo quando qualcuno ti manda uno screenshot dei tuoi dati.
Q: Cos'è OWASP e perché è rilevante per le PMI italiane?
A: OWASP (Open Worldwide Application Security Project) è un'organizzazione no-profit che pubblica le linee guida di riferimento per la sicurezza delle applicazioni web. Per le PMI è utile perché la Top 10 OWASP elenca i vettori di attacco più comuni, indipendentemente dalla dimensione dell'azienda: SQL injection, broken authentication, misconfiguration. Seguirla non richiede un budget enterprise.
Q: Ogni quanto fare un penetration test su un'applicazione web custom?
A: Dipende dalla criticità dell'applicazione. Per un gestionale interno con dati sensibili, almeno una volta all'anno e dopo ogni rilascio major. Per applicazioni esposte a utenti esterni o che trattano pagamenti, ogni sei mesi è una soglia ragionevole. Dopo una modifica architetturale importante, un pen test puntuale è sempre consigliato.
Q: Il GDPR si applica anche al software sviluppato internamente?
A: Sì. Se il software tratta dati personali di utenti, dipendenti o clienti, il GDPR si applica indipendentemente dal fatto che sia custom o SaaS. Questo include log di accesso, profilazione, gestione dei consensi, diritto all'oblio. Il codice custom spesso espone rischi maggiori proprio perché non ha passato audit di terze parti.
Q: Qual è la differenza tra hardening e penetration test?
A: L'hardening è preventivo: si interviene sulla configurazione del server, del framework e del database per ridurre la superficie di attacco prima che qualcuno ci provi. Il penetration test è un'analisi attiva: un professionista simula un attacco reale per trovare le vulnerabilità che l'hardening non ha coperto. I due approcci si completano, non si sostituiscono.
Q: Le vulnerabilità del software custom sono più pericolose di quelle di un SaaS?
A: Non necessariamente più pericolose, ma spesso meno visibili. Un SaaS ha team dedicati alla sicurezza e patch distribuite automaticamente. Un'applicazione custom dipende dal team che l'ha sviluppata: se non c'è un processo di aggiornamento delle dipendenze e di revisione del codice, le vulnerabilità restano aperte più a lungo.
Se gestisci un'applicazione web custom e vuoi capire concretamente dove sei esposto, in Press Start facciamo analisi tecniche della postura di sicurezza partendo dalla checklist qui sopra. Raccontaci il tuo caso
