Audit di sicurezza sul sito aziendale: guida pratica per non lasciare porte aperte

Il sito web aziendale è spesso il punto di accesso più esposto della tua infrastruttura digitale: è pubblico per definizione, aggiornato di frequente e collegato a sistemi interni come CRM, database e piattaforme di pagamento. Eppure, molte aziende lo trattano come una vetrina statica, trascurando i rischi reali che nasconde. Un audit di sicurezza non è un'attività riservata alle grandi corporation: è un processo strutturato e ripetibile che qualsiasi organizzazione dovrebbe eseguire almeno una volta l'anno, o dopo ogni aggiornamento significativo. Non si tratta di cercare hacker sotto il letto, ma di mappare sistematicamente le vulnerabilità prima che qualcun altro le trovi al posto tuo. In questo articolo vedremo come condurre un audit concreto, quali strumenti usare, cosa controllare e come interpretare i risultati per prendere decisioni efficaci — senza trasformare l'esercizio in un documento che finisce nel cassetto.

Fase 1: ricognizione e mappatura della superficie di attacco

Prima di cercare vulnerabilità, devi sapere esattamente cosa stai proteggendo. La fase di ricognizione consiste nel censire tutti i componenti esposti del sito: domini e sottodomini attivi, endpoint API, form di contatto, aree di login, script di terze parti e certificati SSL. Strumenti come Shodan, Subfinder o semplicemente Google Dork (query avanzate su Google) ti permettono di vedere il tuo sito con gli occhi di un attaccante esterno. Un esempio pratico: molte aziende dimenticano sottodomini come staging.nomeazienda.it o old.nomeazienda.it, spesso privi di autenticazione e con versioni datate del CMS. Questi rappresentano vettori di attacco facilmente sfruttabili. In questa fase è utile anche verificare cosa è indicizzato nei motori di ricerca tramite la cache e controllare il file robots.txt, che paradossalmente può rivelare percorsi sensibili che l'azienda voleva nascondere. L'output di questa fase deve essere un inventario completo e aggiornato: è la base su cui costruire tutto il resto dell'audit.

Fase 2: analisi delle vulnerabilità tecniche

Con la superficie di attacco mappata, si passa alla scansione attiva. Gli strumenti più utilizzati in ambito professionale sono OWASP ZAP (gratuito e open source), Nikto per la scansione dei server web e Burp Suite per un'analisi più approfondita delle richieste HTTP. Se il sito gira su WordPress, WooCommerce o altri CMS, WPScan è lo strumento specifico da integrare. Cosa cercare concretamente? Le vulnerabilità più comuni secondo l'OWASP Top 10 includono: SQL injection nei form di ricerca o login, Cross-Site Scripting (XSS) nei campi di input, misconfigurazioni nei header HTTP (assenza di Content-Security-Policy, X-Frame-Options, HSTS), esposizione di file sensibili come .env, backup.zip o phpinfo.php, e autenticazione debole sulle aree amministrative. Un controllo spesso sottovalutato riguarda le dipendenze JavaScript di terze parti: librerie come jQuery o script di analytics possono contenere vulnerabilità note se non aggiornate. Strumenti come Snyk o Retire.js analizzano automaticamente queste dipendenze. Ogni vulnerabilità trovata va documentata con livello di criticità (CVSS score), prova di concetto e impatto potenziale sul business.

Fase 3: verifica delle configurazioni e delle policy di accesso

La maggior parte delle violazioni non avviene sfruttando vulnerabilità sofisticate, ma errori di configurazione banali. Questa fase dell'audit si concentra su tre aree principali. Prima: la configurazione del server. Verifica che il server web (Apache, Nginx, ecc.) non esponga la versione del software negli header di risposta, che la directory listing sia disabilitata e che i metodi HTTP non necessari come TRACE o DELETE siano bloccati. Strumenti come SecurityHeaders.com forniscono un report immediato sugli header HTTP del sito. Seconda: la gestione degli accessi. Controlla chi ha accesso al pannello amministrativo, se è attiva l'autenticazione a due fattori (2FA), se le password predefinite sono state cambiate e se i log di accesso vengono monitorati. Terza: le configurazioni SSL/TLS. Non basta avere un certificato valido: verifica che siano disabilitati i protocolli obsoleti come TLS 1.0 e 1.1, che la cipher suite sia aggiornata e che il certificato non sia in scadenza. SSL Labs offre un test gratuito e dettagliato. Un sito con SSL grade A può comunque avere gravi problemi di configurazione a livello applicativo: i due aspetti vanno verificati separatamente.

Fase 4: interpretare i risultati e definire le priorità di intervento

Un audit ben eseguito produce un elenco di vulnerabilità che può sembrare scoraggiante. L'errore più comune è cercare di risolvere tutto subito, disperdendo risorse su problemi a basso impatto mentre quelli critici restano aperti. Il metodo corretto è la prioritizzazione basata sul rischio reale, non solo sul punteggio tecnico. Una SQL injection su un form di ricerca che accede a dati pubblici è meno urgente di una misconfiguration che espone credenziali di accesso al database. Per ogni vulnerabilità, valuta tre fattori: probabilità di sfruttamento (è pubblica? Esistono exploit già pronti?), impatto sul business (perdita di dati, downtime, danni reputazionali) e facilità di remediation (patch disponibile, modifica di configurazione, refactoring del codice). Organizza i risultati in una matrice rischio/effort e definisci tre livelli di intervento: immediato (entro 24-48 ore per le criticità), breve termine (entro 30 giorni) e medio termine (entro il trimestre). Il report finale non deve essere un documento tecnico incomprensibile per il management: include sempre una executive summary con i rischi in linguaggio business e le azioni raccomandate con stima dei costi e dei benefici attesi.

Punti chiave

• Inizia sempre dall'inventario completo della superficie di attacco — sottodomini dimenticati e file esposti sono tra i vettori più sfruttati

• Le vulnerabilità più pericolose spesso non sono tecnicamente sofisticate: misconfigurazioni, credenziali deboli e dipendenze obsolete causano la maggior parte delle violazioni reali

• Prioritizza gli interventi in base al rischio di business reale, non solo al punteggio tecnico: un audit utile è quello che produce azioni concrete, non report archiviati

Un audit di sicurezza sul sito aziendale non è un progetto una tantum: è un processo che deve diventare parte del ciclo di vita del sito, integrato nelle routine di sviluppo e aggiornamento. Le minacce evolvono, i CMS si aggiornano, le dipendenze cambiano — e con loro cambia la superficie di rischio. Se non hai ancora condotto un audit strutturato, il momento migliore per iniziare è adesso: parti dalla ricognizione, usa gli strumenti gratuiti disponibili e documenta quello che trovi. Se invece hai bisogno di un'analisi approfondita o di un penetration test certificato, considera di affidarti a un professionista con certificazioni OSCP o CEH. La sicurezza non è un costo: è la condizione minima per operare con credibilità nel digitale.