Audit di Sicurezza del Sito Web: La Checklist Completa per il 2025

Gestire un sito web senza audit di sicurezza regolari e come lasciare la porta dell'ufficio aperta sperando che nessuno entri. Prima o poi, qualcuno lo fara. Un audit di sicurezza fornisce un quadro chiaro delle difese e di cosa va corretto prima che un attaccante trovi le falle.

In Envestis a Lugano, eseguiamo valutazioni di sicurezza per aziende in tutta la Svizzera e oltre. Questo articolo illustra ogni fase di un audit professionale di sicurezza web, cosi saprete esattamente cosa aspettarvi e cosa richiedere al vostro fornitore di sicurezza.

Cos'e un Audit di Sicurezza del Sito Web?

Un audit di sicurezza del sito web e un esame sistematico della vostra applicazione web, della configurazione del server e dell'infrastruttura di supporto. L'obiettivo e individuare vulnerabilita, errori di configurazione e punti deboli prima che vengano sfruttati da attori malevoli.

Un audit serio va ben oltre l'esecuzione di uno scanner automatizzato. Combina strumenti automatici con analisi manuale e interpretazione esperta. Il risultato e un elenco prioritizzato di problemi con passi concreti di rimedio.

Valutazione Esterna vs Interna

Esistono due prospettive principali per un audit di sicurezza:

• Valutazione esterna: Esamina il sito dall'esterno, come lo vedrebbe un attaccante su internet. Copre servizi accessibili pubblicamente, porte aperte, file esposti e configurazioni errate visibili esternamente.
• Valutazione interna: Esamina l'ambiente server dall'interno, inclusi permessi dei file, configurazione del server, sicurezza del database ed esposizione della rete interna. Richiede credenziali di accesso.

La maggior parte degli audit inizia dall'esterno. Se il budget e limitato, partite da li. Una valutazione esterna intercetta i problemi piu probabilmente sfruttabili da attaccanti opportunistici.

Fase 1: OSINT (Open Source Intelligence)

Prima di toccare direttamente il sito, un buon auditor raccoglie informazioni disponibili pubblicamente. Questa e la fase OSINT, e spesso rivela piu di quanto ci si aspetti.

Cosa Copre l'OSINT

• Record DNS: MX, TXT, CNAME, A, AAAA. Rivelano il provider di hosting, i servizi email e talvolta hostname interni che non dovrebbero essere pubblici.
• Dati WHOIS: Dettagli di registrazione del dominio, registrar, date di creazione e scadenza. Domini scaduti o in prossima scadenza rappresentano un rischio.
• Enumerazione sottodomini: Strumenti come subfinder, amass o i log di certificate transparency rivelano sottodomini dimenticati. Ambienti di staging, vecchi siti di test e pannelli di amministrazione compaiono spesso qui.
• Indirizzi email: Email aziendali trapelate da breach (verificate su database come Have I Been Pwned) possono essere usate per credential stuffing o phishing.
• Repository di codice: Repository GitHub pubblici a volte contengono chiavi API, credenziali database o documentazione interna.
• Dati storici: La Wayback Machine e le pagine in cache possono rivelare vecchie strutture del sito, pagine rimosse e contenuti sensibili precedentemente esposti.

Perche l'OSINT Conta

Gli attaccanti iniziano con l'OSINT. Se il vostro sito di staging su staging.azienda.ch esegue un WordPress non aggiornato con credenziali predefinite, nessun livello di hardening sul sito di produzione ha importanza. L'OSINT trova gli angoli dimenticati.

Fase 2: Technology Fingerprinting

Successivamente, l'auditor identifica lo stack tecnologico che alimenta il vostro sito web. Conoscere la versione esatta di CMS, framework, software del server e plugin e fondamentale perche ciascuno ha il proprio set di vulnerabilita note.

Cosa Viene Identificato

Componente	Come Viene Rilevato	Perche Importa
Web server	Header di risposta HTTP (header Server)	Exploit specifici per versione (es. Apache 2.4.49 path traversal)
CMS	Meta tag, percorsi file, pagine di login	WordPress, Joomla, Drupal hanno profili di vulnerabilita unici
Framework JavaScript	Analisi del codice sorgente, percorsi file specifici	Versioni obsolete di jQuery, Angular o React possono avere falle XSS
Plugin/estensioni	Pattern URL, commenti HTML, riferimenti CSS/JS	I plugin sono il vettore di attacco #1 nei siti basati su CMS
Linguaggio server-side	Estensioni file, messaggi di errore, cookie	PHP, Python, Node.js hanno rischi di misconfiguration diversi
CDN / WAF	Header di risposta, range IP, analisi comportamentale	Conoscere il CDN aiuta a valutare le protezioni attive

Strumenti come Wappalyzer, BuiltWith e whatweb automatizzano buona parte del processo, ma gli auditor esperti controllano anche manualmente. Gli strumenti automatici non rilevano setup personalizzati e indicatori deliberatamente nascosti.

Fase 3: Scansione delle Vulnerabilita

Con lo stack tecnologico identificato, l'auditor esegue scansioni mirate delle vulnerabilita. Questa e la fase che la maggior parte delle persone associa al termine "audit di sicurezza."

Strumenti di Scansione Automatizzata

Gli auditor professionisti combinano tipicamente diversi strumenti:

• Nmap: Scansione delle porte e rilevamento dei servizi. Trova porte aperte che non dovrebbero essere esposte (porte database, interfacce admin, FTP).
• Nikto: Scanner del web server che verifica file pericolosi, software server obsoleto e misconfigurazioni comuni.
• OWASP ZAP o Burp Suite: Scanner di applicazioni web che analizzano il sito e testano falle di injection, XSS, CSRF e altre vulnerabilita OWASP Top 10.
• WPScan / CMSScan: Scanner specifici per CMS che verificano plugin, temi e versioni core vulnerabili.
• SSLyze / testssl.sh: Analisi dedicata della configurazione SSL/TLS.

Test Manuali

Gli scanner automatici intercettano circa il 60-70% delle vulnerabilita comuni. Il resto richiede test manuali. Auditor esperti verificheranno:

• Meccanismi di autenticazione (protezioni brute force, gestione sessioni, flussi di reset password)
• Controlli di autorizzazione (l'utente A puo accedere ai dati dell'utente B?)
• Abuso della logica di business (manipolazione prezzi, stacking coupon, bypass rate limit)
• Funzionalita di upload file per upload non limitati
• Endpoint API per information disclosure o autenticazione mancante

Fase 4: Analisi SSL/TLS

La configurazione SSL/TLS e uno degli aspetti piu critici della sicurezza del sito. Un certificato mal configurato o una versione di protocollo obsoleta possono esporre tutto il traffico tra gli utenti e il server.

Cosa Viene Controllato

• Validita del certificato: Il certificato e attuale? Copre tutti i sottodomini? La catena di trust e completa?
• Versioni del protocollo: TLS 1.2 e 1.3 dovrebbero essere gli unici protocolli abilitati. TLS 1.0 e 1.1 sono deprecati. SSLv3 e un finding critico.
• Suite di cifratura: Cifrari deboli (RC4, DES, cifrari export) devono essere disabilitati. Il server dovrebbe preferire suite di cifratura forti e supportare il forward secrecy.
• HSTS: HTTP Strict Transport Security dovrebbe essere abilitato con un max-age ragionevole (almeno 6 mesi).
• Certificate transparency: Il certificato dovrebbe essere registrato nei CT log per tracciabilita.
• OCSP stapling: Migliora sia la sicurezza che le performance dei controlli di revoca del certificato.

Problemi SSL/TLS Comuni che Troviamo

Nei nostri audit presso aziende svizzere, i problemi SSL/TLS piu frequenti sono:

1. Header HSTS mancante (molto comune, facile da risolvere)
2. TLS 1.0/1.1 ancora abilitati (specialmente su installazioni Windows Server piu vecchie)
3. Catene di certificati incomplete che causano warning su alcuni dispositivi
4. Certificati wildcard usati dove non dovrebbero
5. Contenuto misto (pagina HTTPS che carica risorse HTTP)

Fase 5: Controllo Autenticazione Email

Il vostro sito web e la vostra email condividono lo stesso dominio. Un'autenticazione email debole rende il dominio vulnerabile allo spoofing, che gli attaccanti usano per campagne di phishing rivolte ai vostri clienti e partner.

SPF (Sender Policy Framework)

SPF indica ai server di posta riceventi quali indirizzi IP sono autorizzati a inviare email per conto del vostro dominio. Problemi comuni includono:

• Record SPF completamente mancante
• Record SPF con +all (permette a chiunque di inviare come il vostro dominio)
• Troppi lookup DNS (SPF ha un limite di 10 lookup)
• Inclusione di servizi non piu utilizzati

DKIM (DomainKeys Identified Mail)

DKIM aggiunge una firma crittografica alle email in uscita. L'auditor verifica che DKIM sia configurato correttamente per tutti i servizi di invio (server mail, strumenti marketing, CRM, ecc.).

DMARC (Domain-based Message Authentication)

DMARC lega SPF e DKIM con una policy che indica ai server riceventi cosa fare quando l'autenticazione fallisce. Una policy DMARC corretta progredisce da p=none (monitoraggio) a p=quarantine e infine p=reject.

Troviamo regolarmente aziende svizzere senza alcun record DMARC, lasciando il dominio completamente esposto allo spoofing.

Fase 6: Security Headers

Gli header di sicurezza HTTP sono un livello di difesa critico che molti siti web ignorano completamente. Sono gratuiti da implementare e riducono significativamente la superficie di attacco.

Security Headers Essenziali

Header	Scopo	Valore Raccomandato
Content-Security-Policy	Previene XSS e injection di dati	Policy restrittiva che limita le sorgenti script
X-Content-Type-Options	Previene MIME type sniffing	nosniff
X-Frame-Options	Previene clickjacking	DENY o SAMEORIGIN
Referrer-Policy	Controlla le informazioni referrer	strict-origin-when-cross-origin
Permissions-Policy	Controlla le funzionalita del browser	Disabilitare funzionalita non usate (camera, microfono, ecc.)
Strict-Transport-Security	Forza HTTPS	max-age=31536000; includeSubDomains

Approfondimento Content Security Policy

CSP merita attenzione speciale perche e sia il piu potente che il piu comunemente mal configurato tra i security header. Una CSP corretta:

• Blocca gli script inline (previene la maggior parte degli attacchi XSS)
• Autorizza solo le sorgenti script necessarie
• Usa nonce o hash per script inline che non possono essere esternalizzati
• Segnala le violazioni a un endpoint di monitoraggio

Iniziate con Content-Security-Policy-Report-Only per monitorare prima di applicare. Molti siti si rompono quando CSP viene implementato per la prima volta perche si affidano a script inline o risorse di terze parti di cui non erano a conoscenza.

Fase 7: Controlli Specifici CMS

Se il vostro sito funziona su un CMS come WordPress, Joomla o Drupal, ci sono aspetti di sicurezza specifici della piattaforma che richiedono attenzione dedicata.

Checklist WordPress

• Versione core aggiornata (verificare sulla pagina release di wordpress.org)
• Tutti i plugin aggiornati e attivamente mantenuti
• Plugin e temi inutilizzati rimossi (non solo disattivati)
• Username admin predefinito cambiato
• Pagina login protetta (rate limiting, 2FA o restrizione IP)
• XML-RPC disabilitato se non necessario (vettore comune per brute-force)
• Modifica file disabilitata in wp-config.php (DISALLOW_FILE_EDIT)
• Prefisso database cambiato dal predefinito wp_
• Directory listing disabilitato
• wp-config.php non accessibile via web
• Modalita debug disabilitata in produzione

Sicurezza CMS Generale

• Interfaccia admin accessibile solo da IP fidati o VPN
• Policy password forte applicata per tutti gli utenti
• Restrizioni upload file configurate correttamente
• Messaggi di errore che non rivelano informazioni di sistema
• Aggiornamenti automatici abilitati per patch di sicurezza

Fase 8: Impatto su Performance e SEO

Sicurezza e performance sono collegate piu strettamente di quanto molti pensino. I problemi di sicurezza possono danneggiare direttamente il posizionamento sui motori di ricerca e l'esperienza utente.

Come la Sicurezza Influenza il SEO

• Blacklisting: Google segnala i siti compromessi con avvisi "Questo sito potrebbe essere stato hackerato," devastando il traffico organico.
• HTTPS: Google usa HTTPS come segnale di ranking. Gli avvisi di contenuto misto riducono fiducia e posizionamento.
• Velocita pagina: Misure di sicurezza mal configurate (regole WAF troppo aggressive, redirect ridondanti) rallentano il sito.
• Spam injection: Spam SEO iniettato dagli attaccanti (keyword farmaceutiche, link nascosti) attiva penalita manuali.

Come Interpretare i Risultati dell'Audit

Un report professionale di audit di sicurezza categorizza i risultati per gravita:

Livelli di Gravita

1. Critico: Vulnerabilita immediatamente sfruttabili che potrebbero portare alla compromissione completa del sistema. Esempi: SQL injection, esecuzione remota di codice, credenziali admin predefinite. Correggere entro 24 ore.
2. Alto: Vulnerabilita serie che richiedono condizioni specifiche. Esempi: stored XSS, bypass autenticazione, esposizione dati sensibili. Correggere entro 1 settimana.
3. Medio: Vulnerabilita che richiedono interazione utente o condizioni specifiche. Esempi: reflected XSS, CSRF, security headers mancanti. Correggere entro 1 mese.
4. Basso: Problemi minori che forniscono informazioni agli attaccanti o indicano configurazione subottimale. Esempi: disclosure versione server, messaggi di errore verbosi. Correggere entro 3 mesi.
5. Informativo: Raccomandazioni di best practice e osservazioni. Non direttamente sfruttabili ma da considerare.

Cosa Fare Dopo un Audit

Ricevere un report di audit e solo l'inizio. Ecco un approccio pratico per agire sui risultati:

Azioni Immediate (Settimana 1)

1. Correggere tutte le vulnerabilita critiche. Nessuna eccezione, nessun ritardo.
2. Cambiare credenziali compromesse o deboli.
3. Aggiornare tutto il software con vulnerabilita note.
4. Disabilitare servizi o funzionalita segnalati come superficie di attacco non necessaria.

Azioni a Breve Termine (Mese 1)

1. Affrontare i finding ad alta gravita.
2. Implementare i security headers mancanti.
3. Configurare l'autenticazione email (SPF, DKIM, DMARC).
4. Configurare monitoraggio e alerting per problemi futuri.
5. Rivedere e aggiornare le procedure di backup.

Azioni a Lungo Termine (Trimestre 1)

1. Affrontare i finding medi e bassi.
2. Stabilire un programma regolare di patching.
3. Pianificare un audit di follow-up per verificare le correzioni.
4. Sviluppare un documento di security policy.
5. Formare il personale sulla consapevolezza della sicurezza.

Programmare Audit Regolari

Un singolo audit e un'istantanea. I siti web cambiano costantemente: nuovi contenuti, nuovi plugin, nuove funzionalita. Raccomandiamo:

• Audit annuale completo: Valutazione completa con test manuali.
• Scansioni automatiche trimestrali: Per intercettare nuove vulnerabilita e drift di configurazione.
• Monitoraggio continuo: Uptime, scadenza certificato SSL, reputazione dominio e controllo security headers.

Richiedere un Audit di Sicurezza Professionale

Se gestite un sito web aziendale, specialmente uno che tratta dati dei clienti, elabora pagamenti o rappresenta il vostro brand, un audit di sicurezza professionale non e opzionale. E una pratica aziendale fondamentale.

Envestis fornisce audit completi di sicurezza web per aziende a Lugano, in tutta la Svizzera e a livello internazionale. I nostri audit seguono la metodologia descritta in questo articolo e rispettano gli standard di settore inclusi OWASP Testing Guide e PTES.

Contattateci per programmare il vostro audit di sicurezza del sito web e ottenere un quadro chiaro delle vostre difese.