Per proteggere il sito web aziendale servono poche abitudini, ma costanti: applicare gli aggiornamenti di sicurezza appena escono, difendere gli accessi con password uniche e un secondo fattore, tenere backup fuori dal server e provarli, cifrare il traffico con HTTPS e sapere in anticipo chi interviene se qualcosa va storto. Nessuna di queste richiede un reparto informatico; richiede che qualcuno ne sia responsabile, per iscritto.
Perché qualcuno dovrebbe attaccare il sito di una piccola azienda?
Spesso non c'entra chi sei. Quando esce la correzione di una vulnerabilità, le informazioni per sfruttarla diventano di fatto pubbliche, come ricorda la guida alla sicurezza di WordPress, e i siti rimasti indietro diventano bersagli facili. Allo stesso modo, programmi automatici provano in serie utenti e password rubati ad altri servizi: è il credential stuffing descritto dall'OWASP.
Una volta dentro, chi attacca usa il sito per i propri scopi: pagine di spam inserite di nascosto, reindirizzamenti verso siti truffa, phishing, codice dannoso eseguito nel browser dei visitatori. Google lo segnala nel report Problemi di sicurezza di Search Console e può mostrare un avviso accanto ai risultati di ricerca, o una pagina di avviso nel browser prima di aprire il sito. Per un'azienda significa contatti persi, fiducia da ricostruire e, se sono coinvolti dati personali, obblighi verso il Garante.
Quali sono i punti deboli da cui si entra?
Un buon riferimento è la Top 10 dell'OWASP, la classifica dei rischi più critici per le applicazioni web, aggiornata nel 2025 dalla fondazione che si occupa di sicurezza del software. Letta con gli occhi di chi ha un sito aziendale, dice dove guardare per primo:
- controlli di accesso difettosi, cioè pagine o funzioni riservate raggiungibili da chi non dovrebbe: è il primo rischio della classifica
- configurazioni sbagliate: pannelli esposti, impostazioni di fabbrica, file di prova dimenticati sul server
- componenti vulnerabili o non aggiornati, compresi plugin, temi e librerie, che l'OWASP ora fa rientrare nei problemi della catena di fornitura del software
- iniezione di codice attraverso moduli e parametri che il sito non controlla
- autenticazione debole: password riutilizzate, nessun secondo fattore, tentativi di accesso illimitati
Come si aggiorna un sito senza romperlo?
Gli aggiornamenti sono la difesa più semplice, e il timore che rompano qualcosa si gestisce con una procedura, non rimandandoli. WordPress installa da solo, per impostazione predefinita, gli aggiornamenti minori del core, cioè le versioni di manutenzione e sicurezza, e dalla versione 5.5 puoi attivare gli aggiornamenti automatici anche per singoli plugin e temi. Per il resto serve un metodo ripetibile:
- precedenza alle correzioni di sicurezza, da applicare appena escono; le novità funzionali possono aspettare il giro successivo
- backup completo subito prima di aggiornare, così puoi tornare indietro in fretta
- prova degli aggiornamenti importanti su una copia del sito (ambiente di staging) protetta da password
- controllo delle pagine chiave dopo ogni aggiornamento: home, moduli, carrello e pagamento
- rimozione di plugin, temi e dipendenze che non usi, perché ogni componente in più allarga la superficie d'attacco, come raccomanda l'OWASP
- attenzione agli avvisi della directory ufficiale: WordPress.org segnala i plugin chiusi, anche per problemi di sicurezza, e quelli non testati con le ultime tre versioni principali
Vale anche per i siti su misura in Next.js e React, quelli che realizziamo noi: cambia il tipo di manutenzione, non la necessità. A marzo 2025, per esempio, Next.js ha corretto una vulnerabilità critica che permetteva di aggirare i controlli di autorizzazione nel middleware. Su questi progetti servono il monitoraggio delle dipendenze, con strumenti come Dependabot o npm audit, e rilasci regolari. Se stai ancora scegliendo la piattaforma, trovi pro e contro nel confronto tra WordPress e Next.js; se il sito è così datato che non si riesce più ad aggiornarlo, conviene valutare un restyling.
Chi ha le chiavi del sito?
In un sito si può entrare anche senza nessun difetto tecnico, con credenziali valide: una password riutilizzata, l'account di un ex collaboratore mai chiuso, lo stesso utente amministratore condiviso da tre persone. Secondo l'OWASP, la maggior parte degli attacchi riusciti all'autenticazione si deve all'uso della password come unico fattore. Le contromisure sono organizzative prima che tecniche:
- un account nominativo per ogni persona, con i soli permessi che le servono, e nessun amministratore condiviso
- autenticazione a più fattori su CMS, hosting, registrar del dominio, DNS ed email: l'Agenzia per la cybersicurezza nazionale la raccomanda in particolare per posta, servizi cloud e accessi privilegiati
- password lunghe e uniche, custodite in un gestore di password
- un limite ai tentativi di accesso falliti, con un avviso quando si ripetono
- una revisione degli accessi ogni volta che cambia un collaboratore o un fornitore
Un dettaglio da non dimenticare: gli account del registrar e del DNS valgono quanto la password del sito, perché chi li controlla può dirottare dominio ed email. Se non sai a nome di chi sono, è il primo controllo da fare; nel contratto di sviluppo va scritto chi li intesta e chi li gestisce.
Quali backup servono, e come sai che funzionano?
Un backup serve a una cosa sola: rimettere online il sito com'era prima del problema. Per riuscirci deve contenere tutto (file, database, immagini caricate, configurazioni, ed eventualmente le caselle email se stanno sullo stesso hosting) e trovarsi fuori dal server che deve proteggere. La regola classica è il 3-2-1 descritto dalla CISA, l'agenzia statunitense per la cybersicurezza: tre copie dei dati, su due tipi di supporto diversi, di cui una conservata altrove.
La frequenza dipende da quanto cambia il sito. Per un sito vetrina aggiornato di rado può bastare una copia a ogni modifica più una periodica; un e-commerce che riceve ordini ogni giorno ha bisogno di copie del database molto più ravvicinate. Decidi anche per quanto tempo conservarle, perché una violazione scoperta tardi si ripara solo con una copia precedente all'attacco. Nei siti su misura il codice vive già in un repository con tutta la sua storia, ma il database e i file caricati dagli utenti vanno salvati a parte.
Il passaggio che fa la differenza è la prova. L'ACN consiglia test periodici di ripristino completo, e l'articolo 32 del GDPR indica tra le misure di sicurezza la capacità di ripristinare tempestivamente l'accesso ai dati e una procedura per verificare regolarmente che le misure funzionino. In pratica, ogni tanto qualcuno deve ripristinare il sito da backup su un ambiente di prova e controllare che vada tutto, moduli e pagamenti compresi. Ricorda anche che i backup contengono dati personali: vanno protetti come il sito e conservati non più a lungo del necessario, come chiede il principio di limitazione della conservazione dello stesso regolamento.
HTTPS, intestazioni di sicurezza e firewall: cosa controllare?
Il certificato che abilita HTTPS cifra il traffico tra visitatore e sito, e oggi deve rinnovarsi da solo. Il CA/Browser Forum, l'organismo che fissa i requisiti per questi certificati, ha deciso di ridurne la validità massima per tappe, da marzo 2026 a marzo 2029, passando da poco più di un anno a meno di due mesi. Con certificati così brevi, affidarsi al rinnovo manuale vuol dire prima o poi ritrovarsi con il browser che avvisa i visitatori di una connessione non sicura: chiedi se il rinnovo è automatico e chi riceve l'avviso quando fallisce.
Le intestazioni di sicurezza sono istruzioni che il server manda al browser insieme alla pagina. Le più utili sono HSTS, che impone al browser di usare sempre HTTPS, la Content Security Policy, che limita da dove possono arrivare gli script e aiuta contro l'iniezione di codice e il clickjacking, e X-Content-Type-Options, che impedisce al browser di interpretare un file in modo diverso da come è dichiarato. Puoi vedere come è messo il tuo sito con l'HTTP Observatory di Mozilla, che analizza le intestazioni e segnala cosa manca.
Un firewall applicativo (WAF), che molti servizi di CDN e hosting offrono, filtra il traffico sospetto prima che arrivi al sito. Aiuta, ma non sostituisce aggiornamenti e accessi protetti. Conta anche quanto esponi: l'ACN consiglia di limitare le piattaforme raggiungibili da internet a quelle strettamente necessarie, e per un sito vuol dire pannelli di amministrazione, ambienti di prova e vecchie installazioni dimenticate.
Il sito è stato violato: cosa fare nelle prime ore?
La tentazione è cancellare subito tutto ciò che sembra strano. Conviene invece seguire un ordine:
- metti online una pagina di manutenzione, così i visitatori non vengono esposti
- conserva i log del server e una copia del sito compromesso, che servono a capire da dove sono entrati
- cambia tutte le credenziali (CMS, hosting, database, accesso ai file, registrar, email) e attiva il secondo fattore dove manca
- ripristina da un backup pulito precedente all'attacco, oppure ripulisci i file uno per uno se non ne hai
- trova e chiudi la porta d'ingresso, per esempio un componente vulnerabile o un accesso rubato, prima di rimettere online
- controlla il report Problemi di sicurezza di Search Console e, a correzione fatta, richiedi l'esame a Google
Se l'incidente ha toccato dati personali (contatti arrivati dai moduli, anagrafiche dei clienti, ordini), valuta subito se va notificato. Il GDPR prevede che il titolare notifichi la violazione al Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando ne è venuto a conoscenza, salvo che il rischio per le persone sia improbabile; il Garante offre una procedura online e uno strumento di autovalutazione. Se il rischio è elevato vanno avvisati anche gli interessati, e ogni violazione va comunque documentata.
Cosa chiedere a chi gestisce il tuo sito?
Che il sito lo segua un collaboratore interno o un fornitore, queste risposte dovrebbero essere scritte da qualche parte, e non solo nella memoria di qualcuno:
- ogni quanto vengono applicati gli aggiornamenti, e chi decide quelli urgenti
- dove stanno i backup, per quanto tempo vengono conservati e quando è stato fatto l'ultimo ripristino di prova
- chi riceve l'allarme se il sito va offline o viene modificato senza autorizzazione
- chi intesta e chi custodisce le credenziali di dominio, DNS, hosting e CMS
- cosa succede in caso di incidente: chi chiami, in quanto tempo viene preso in carico, chi valuta la notifica al Garante
- se il fornitore vede dati personali, il contratto previsto dall'articolo 28 del GDPR
Se la tua azienda rientra tra i soggetti della normativa NIS2, recepita in Italia con il decreto legislativo 138 del 2024, gli obblighi riguardano l'intera infrastruttura informatica e non solo il sito: registrazione, misure di sicurezza, notifica degli incidenti significativi. Il portale dell'ACN spiega chi è coinvolto e con quali scadenze.
Aggiornamenti, backup e monitoraggio possono anche smettere di essere un tuo pensiero: nella pagina sulla gestione dei siti web trovi cosa comprende il servizio, anche per i siti WordPress.
