Tecnologie

Sicurezza sito web 2026: 12 controlli che ogni sito dovrebbe superare

Checklist sicurezza sito web 2026: HTTPS, CSP, headers, autenticazione, backup, plugin. 12 controlli con strumenti gratuiti per misurare ognuno.

Stefano Prandi — 2026-06-25

Lavoro con i siti web da più di vent'anni e ti dico una cosa che a inizio carriera non avrei mai pensato di dire: oggi il rischio reale per un sito di una PMI italiana non è "essere attaccato da un hacker russo che vuole rubarti i dati". È molto più banale e molto più frequente. È un bot automatico che scansiona tutto l'internet a caccia di una versione di WordPress non aggiornata, di un plugin con una CVE pubblica del 2024, di un pannello admin esposto su /wp-admin senza 2FA. E quando lo trova, ti usa per mandare spam, mettere redirect verso siti di scommesse, o caricare pagine di phishing.

Non è uno scenario teorico: nel 2025 ho ripulito personalmente sei siti compromessi. In tutti i casi la causa era una di queste tre: plugin abbandonato, password admin debole, oppure assenza totale di headers di sicurezza. Tutte e tre prevenibili in mezza giornata di lavoro.

In questo articolo ti passo la checklist che applico sui siti che gestisco e su quelli che faccio audit per i clienti nuovi. Sono 12 controlli concreti, con per ciascuno lo strumento gratuito che usi per verificare se il tuo sito li supera. Alla fine ti dico anche cosa fare nelle prime ore se ti accorgi che il sito è stato bucato.

1. HTTPS obbligatorio + HSTS

Banale? Sì. Eppure ancora oggi trovo siti italiani che girano in HTTP puro, o con certificato self-signed scaduto, o con HTTPS attivo ma il contenuto misto (http:// dentro pagine https://) che fa apparire il lucchetto rotto.

HTTPS oggi è gratis grazie a Let's Encrypt, si attiva con un click su qualunque hosting decente. Ma non basta: devi aggiungere HSTS (HTTP Strict Transport Security), che dice al browser "per il prossimo anno carica questo dominio solo via HTTPS, niente eccezioni". Senza HSTS un attaccante può ancora intercettare la prima connessione e fare downgrade.

Test gratis: SSL Labs. Inserisci il dominio, aspetta 90 secondi, devi vedere voto A o A+. Sotto la B significa che hai cipher deboli, protocolli vecchi (TLS 1.0/1.1) o catena di certificati rotta.

2. Headers di sicurezza (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy)

Questo è il punto su cui inciampano il 90% dei siti che faccio audit. Gli headers di sicurezza sono righe di configurazione che il server manda al browser per dirgli "comportati in modo paranoico". Costano zero, si configurano una volta sola, eliminano intere classi di attacchi.

I quattro che servono sempre:

Content-Security-Policy: definisce le fonti consentite di script, stili, immagini, font. Blocca XSS quasi interamente.
X-Frame-Options: DENY (o SAMEORIGIN): impedisce che il tuo sito venga embeddato in un iframe esterno, evitando clickjacking.
X-Content-Type-Options: nosniff: impedisce al browser di interpretare un file come tipo diverso da quello dichiarato.
Referrer-Policy: strict-origin-when-cross-origin: evita di leakare URL completi (con eventuali token) ai siti esterni.

Aggiungi anche Permissions-Policy per limitare l'accesso a camera, microfono, geolocalizzazione se il tuo sito non li usa.

Test gratis: securityheaders.com. Inserisci il dominio, ti dà un voto da F ad A+. La maggior parte dei siti italiani sta tra E ed F. Arrivare a B è due ore di lavoro, ad A una mezza giornata se hai una CSP complicata da scrivere.

3. Software aggiornato (CMS, plugin, librerie)

Su WordPress, il 95% delle compromissioni passa da un plugin non aggiornato. Non dal core di WordPress (che ormai si aggiorna in automatico per le patch di sicurezza), ma da un plugin che hai installato due anni fa, che non hai mai più aperto, e che il suo sviluppatore ha abbandonato.

La regola: ogni installazione WordPress va guardata almeno una volta a settimana. Plugin con update disponibili → aggiornarli (dopo backup). Plugin che non riceve update da più di 12 mesi → sostituirlo o rimuoverlo. Plugin "premium" il cui developer è sparito → sostituirlo subito.

Stesso discorso per le librerie JavaScript se hai un sito custom: jQuery 1.x, vecchie versioni di Bootstrap, librerie di slider abbandonate sono tutte fonti di XSS noti.

Test gratis: su WordPress installa WPScan CLI (versione gratuita basta per uso personale), su qualunque sito puoi usare Mozilla Observatory per un check generale. Per dipendenze JavaScript: npm audit se hai un build, oppure Snyk per scansionare un repository.

4. Autenticazione 2FA per admin

Password admin forte non basta più, perché spesso viene rubata via phishing o leakata in qualche data breach di altri servizi (il classico cliente che riusa la stessa password di Facebook anche sul suo pannello WordPress). La doppia autenticazione (2FA) aggiunge un secondo fattore — codice generato da app come Authy, Google Authenticator, 1Password — che il bot non può replicare.

Su WordPress si attiva con plugin come Wordfence o WP 2FA. Su pannelli custom o gestionali è una funzionalità da pretendere dal fornitore. Su servizi cloud (Cloudflare, hosting, dominio) è sempre disponibile, va solo attivata: il 70% dei siti che ho visto compromessi aveva la 2FA disponibile ma disattivata.

Test: prova a entrare in incognito col solo username/password. Se entri senza chiedere un secondo fattore, sei vulnerabile a credenziali rubate.

5. Password manager + niente account condivisi

Il "noi usiamo tutti la stessa password admin perché siamo in tre" è la causa di 1 compromissione su 4. Quando uno dei tre cambia computer, posto, dispositivo, o semplicemente lascia l'azienda, quella password gira. Quando un sito di servizi che usa la stessa password viene bucato (succede tutti i mesi: vedi Have I Been Pwned), un bot proverà la combinazione email+password anche sul tuo admin.

Regola dura: ogni utente ha il suo account, ogni account ha la sua password unica, le password sono lunghe (minimo 20 caratteri) e generate da un password manager (Bitwarden gratis, 1Password a pagamento). Niente fogli Excel con password, niente Post-it sul monitor, niente "te la dico al telefono".

Test: chiediti onestamente "se l'unico admin del sito venisse licenziato domani, come revocheremmo il suo accesso?". Se la risposta è "boh, dovremmo cambiare la password e dirla agli altri", il setup è sbagliato.

6. WAF (Cloudflare gratis)

Il Web Application Firewall sta davanti al tuo sito e filtra il traffico prima che arrivi al server. Blocca pattern noti di SQL injection, XSS, brute force sul login, scraping aggressivo, e dà protezione DDoS di base.

La buona notizia: Cloudflare ha un piano gratuito che include WAF, CDN globale, DDoS protection e protezione bot. Si attiva spostando i DNS del dominio sui loro nameserver (15 minuti di lavoro). Per il 90% dei siti vetrina e PMI è più che sufficiente. Per e-commerce ad alto volume si valuta il piano Pro a 20$/mese.

Test: dopo aver attivato Cloudflare, controlla in dashboard la sezione "Security Events". Nelle prime 24h vedrai decine o centinaia di tentativi bloccati: è il rumore di fondo di internet che prima arrivava direttamente al tuo server.

7. Backup automatici off-site + restore testato

Backup che gira sullo stesso server del sito non è un backup: se ti compromettono il server, ti compromettono anche i backup. Backup va sempre fuori dal server (S3, Backblaze B2, Google Drive, un secondo VPS), e va testato.

Il pattern 3-2-1 che cito anche nelle FAQ: 3 copie, 2 supporti diversi, 1 off-site. E "testato" significa che almeno una volta ogni tre mesi qualcuno deve provare a fare un restore su un ambiente staging, partendo solo dal file di backup, senza scorciatoie. Il numero di volte che ho trovato backup corrotti, incompleti o impossibili da ripristinare è imbarazzante.

Test gratis: scarica l'ultimo backup, mettilo su un'installazione vergine di WordPress/CMS, prova a tirarlo su. Se ci riesci in meno di 2 ore senza chiedere aiuto, sei a posto.

8. Logging accessi (fail2ban, server logs)

Sapere chi ha provato a entrare nel tuo sito è la differenza tra "ci hanno bucato sei mesi fa e non lo sappiamo" e "abbiamo bloccato il tentativo in tempo reale". I log devono essere attivi, raccolti e tenuti almeno 90 giorni.

Su server Linux self-managed: fail2ban blocca automaticamente IP che falliscono il login più di N volte. Su hosting gestito devi chiedere al provider l'accesso ai log di accesso (access.log) ed errore (error.log). Su WordPress, plugin come Wordfence loggano i tentativi di login con username/IP/timestamp.

Test gratis: apri il log degli accessi del tuo sito. Cerca le righe con HTTP 401 o 403 e con URL /wp-login.php, /xmlrpc.php, /admin, /.env, /wp-config.php.bak. Se ne trovi più di 50 al giorno (e ne troverai), tutto normale: è il rumore di internet. Se ne trovi 5000 al giorno da pochi IP, hai un attacco brute force in corso e devi bloccare quegli IP.

Non è tecnicamente "sicurezza", è compliance, ma in caso di data breach la differenza tra una multa salata e una sanzione lieve la fa proprio l'avere documentato bene cosa raccogli, perché, e come l'utente può revocare il consenso.

Il minimo sindacale: banner cookie configurato per non caricare script di tracking (Google Analytics, Meta Pixel, ecc.) prima del consenso esplicito; privacy policy aggiornata al GDPR con i diritti dell'utente (accesso, rettifica, cancellazione, portabilità); registro dei trattamenti tenuto da qualche parte. Per i form di contatto: checkbox consenso esplicito separato da quello marketing.

Test gratis: apri il sito in incognito, rifiuta i cookie, poi controlla con DevTools → Application → Cookies se ci sono cookie di terze parti settati comunque. Se ce ne sono, il banner non funziona.

10. Form anti-bot (honeypot, rate limit, captcha invisibile)

I form pubblici (contatti, newsletter, commenti) sono il bersaglio numero uno dello spam automatico, e a volte di attacchi mirati (SQL injection nei campi). Tre tecniche da combinare:

Honeypot: un campo invisibile via CSS che gli umani non compilano e i bot sì. Se è compilato, scarti la submission. Costa zero, blocca il 70% dello spam.
Rate limiting: lo stesso IP non può inviare più di 3 form in 60 secondi. Si configura lato server o via Cloudflare.
Captcha invisibile: hCaptcha, Cloudflare Turnstile, reCAPTCHA v3. Non chiede di cliccare sui semafori, valuta in background se sei umano. Turnstile di Cloudflare è gratis e privacy-friendly.

Test: prova a inviare lo stesso form 10 volte di fila. Se passano tutte, non hai rate limit. Apri DevTools, cerca un campo name="website" o name="url" nascosto: se non c'è, manca l'honeypot.

11. Permessi file e DB minimali

Errore classico su hosting condiviso: tutti i file del sito hanno permessi 777 ("scrivibili da chiunque"). Significa che se un attaccante riesce a piazzare uno script PHP in qualche cartella, può modificare tutto.

Su un'installazione PHP/WordPress sana: file 644, cartelle 755, wp-config.php a 400 o 440. L'utente del database del sito deve avere solo i permessi necessari (SELECT/INSERT/UPDATE/DELETE) sul suo database, mai GRANT, mai accesso ad altri database, mai utente root.

Test gratis: via FTP o SSH, lancia ls -la nella root del sito. Se vedi rwxrwxrwx (777) su file PHP, hai un problema. Su WordPress, plugin come Wordfence hanno una sezione "File integrity" che ti dice cosa è fuori posto.

12. Monitoring uptime (UptimeRobot gratis)

Se il tuo sito viene compromesso o messo offline alle 3 di notte di sabato, vuoi saperlo prima del lunedì mattina. Il monitoring uptime fa ping al sito ogni N minuti e ti manda email/SMS/Telegram se non risponde o se la risposta cambia in modo anomalo.

UptimeRobot ha un piano gratuito che monitora fino a 50 endpoint ogni 5 minuti. Imposta come minimo: la homepage, una pagina interna critica (es. checkout per un e-commerce), il pannello admin. Se hai certificato SSL, attiva anche l'alert "SSL expiring" — ti avvisa 30 giorni prima della scadenza.

Test: simula un downtime. Spegni il sito per due minuti (o cambia URL monitorato a uno che dà 404). Devi ricevere l'alert entro 5-10 minuti. Se non arriva, il monitoring non sta funzionando.

Cosa fare se ti accorgi di essere stato hackerato

Le prime due ore contano più di tutto il resto. Sequenza minima:

Metti il sito in maintenance o staccalo da internet. Niente "vediamo prima cosa è successo": offline, subito. Ogni minuto in più è un altro utente che vede pubblicità di scommesse al tuo posto, o un altro IP che il sito sta usando per mandare spam (e ti porta in blacklist).
Cambia tutte le password: admin sito, hosting, FTP, database, email collegata. Da un dispositivo diverso da quello che usi normalmente, in caso il malware sia anche lato client.
Scarica una copia dello stato attuale (per analisi forense) ma non navigarci sopra.
Ripristina l'ultimo backup pulito (verificato che sia precedente alla compromissione: a volte il primo backup compromesso è di settimane fa).
Indaga la causa prima di rimettere online. Se rimetti online la stessa installazione vulnerabile, ti ribuccano in 24 ore. Il 78% dei siti ricompromessi nel mese successivo è perché non si è chiusa la falla originale.
Notifica al Garante Privacy entro 72h se sono stati esposti dati personali di utenti. Non è opzionale: è legge.

Il costo medio di una bonifica seria sta tra 600 e 1.500€ per un sito vetrina, 2.000-5.000€ per un e-commerce. Tutti soldi che non avresti speso se avessi fatto i 12 controlli sopra.

Cosa succede se ignori la sicurezza

Tornando al tema generale dell'investimento, qui torna utile leggere perché un sito "economico" ti costa di più dopo 2 anni: la sicurezza è esattamente uno di quei costi che non vedi all'inizio e che ti piombano addosso quando è troppo tardi. E se sei nel dubbio se passare a WordPress o stare su una soluzione custom, ho scritto anche sul tema WordPress nel 2026 ha ancora senso — sì, ma con tutta la disciplina che racconto qui sopra.

Vuoi un audit sicurezza del tuo sito?

Se hai letto fin qui e ti è venuto il dubbio "ma il mio sito quanti di questi 12 passa davvero?", la risposta più onesta è: forse meno di quanti pensi. Faccio audit di sicurezza sui siti dei clienti, con report concreto e lista prioritaria di interventi. Scrivimi via stepdesign.prandi.net e ti rispondo entro 24h con un'analisi gratuita preliminare basata sui test pubblici (SSL Labs, securityheaders.com, scansione headers e versioni software esposte). Se servono interventi più profondi parliamo poi di tempi e budget — senza venderti dieci plugin di sicurezza che non servono.

FAQ

Come scopro se il mio sito è stato hackerato?

Cinque segnali ricorrenti: Google Search Console ti manda un avviso 'sito compromesso', il browser mostra l'avviso rosso 'questo sito è ingannevole', l'antivirus dei tuoi visitatori blocca il dominio, ti accorgi di pagine o redirect che non hai creato (spesso verso scommesse, farmacie, contenuti porno), il sito è improvvisamente sparito dalla SERP per il tuo nome. Se vedi anche solo uno di questi, agisci subito: cambia password admin, scollega il sito da internet o mettilo in maintenance, e ripristina un backup pulito prima di indagare la causa.

Quanto costa mettere in sicurezza un sito?

Il setup iniziale (headers, HTTPS, 2FA, WAF Cloudflare gratuito, backup off-site, hardening base) sta tra 250 e 600€ una tantum su un sito esistente medio. Il canone di manutenzione sicurezza (aggiornamenti settimanali, monitoring, restore test trimestrale) va da 30 a 80€/mese per un sito vetrina, da 80 a 200€/mese per e-commerce e gestionali. Sopra a quei numeri di solito ti stanno vendendo aria; sotto, qualcuno sta tagliando i controlli.

Devo avere il Web Application Firewall?

Sì, anche se il tuo sito è 'piccolo'. I bot scansionano l'intero IPv4 in continuazione: per gli attaccanti automatici non esistono siti grandi o piccoli, esistono solo siti vulnerabili o no. La buona notizia è che Cloudflare offre un WAF gratuito più che sufficiente per il 90% dei siti vetrina e PMI, con regole base contro SQL injection, XSS, login brute force e bot scraping. Si attiva in 15 minuti cambiando i DNS.

Ogni quanto fare backup?

Dipende da quanto cambia il contenuto. Sito vetrina che si aggiorna due volte all'anno: backup settimanale è sufficiente. Blog o sito con post mensili: backup giornaliero. E-commerce o gestionale con ordini quotidiani: backup ogni ora dei dati transazionali + backup giornaliero completo. Regola d'oro 3-2-1: tre copie, su due supporti diversi, di cui una off-site. E almeno una volta ogni tre mesi devi provare a fare un restore vero, altrimenti non sai se i backup funzionano.

Cosa è Content Security Policy?

Content Security Policy (CSP) è un'intestazione HTTP che dice al browser quali fonti di script, immagini, font e CSS può caricare. Tradotto: anche se un attaccante riesce a iniettare JavaScript malevolo nel tuo sito, il browser si rifiuta di eseguirlo perché non è nella whitelist. È una delle difese più efficaci contro XSS (cross-site scripting), che è ancora oggi una delle vulnerabilità più sfruttate. Configurarla bene richiede mezza giornata di lavoro ma vale come dieci plugin di sicurezza messi insieme.

Richiedi un preventivo