La maggior parte degli attacchi informatici sfrutta vulnerabilità banali: certificati scaduti, header mancanti, password deboli. Ecco 10 azioni concrete che potete implementare oggi per migliorare drasticamente la sicurezza del vostro sito web.
1. Attivare HTTPS ovunque
HTTPS non è più opzionale — è il minimo. Google penalizza i siti HTTP nel ranking e i browser li segnalano come "Non sicuro".
Azione:
- Installare un certificato SSL/TLS (Let's Encrypt è gratuito)
- Configurare il redirect automatico HTTP → HTTPS
- Verificare che tutte le risorse (immagini, script, CSS) siano caricate via HTTPS
# Nginx - redirect HTTP to HTTPS
server {
listen 80;
server_name example.it;
return 301 https://$server_name$request_uri;
}
2. Configurare gli header di sicurezza HTTP
Gli header di sicurezza sono la prima linea di difesa del browser. Cinque header essenziali:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Perché: HSTS impedisce il downgrade a HTTP, X-Frame-Options previene il clickjacking, e Permissions-Policy limita le API del browser accessibili.
3. Implementare una Content Security Policy
La CSP è lo scudo più efficace contro gli attacchi XSS (Cross-Site Scripting).
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'
Iniziate con una policy restrittiva e allargatela progressivamente in base alle necessità. Usate Content-Security-Policy-Report-Only per testare senza bloccare.
4. Proteggere i cookie
Ogni cookie deve avere i flag di sicurezza appropriati:
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict; Path=/
| Flag | Protezione |
|------|-----------|
| Secure | Trasmesso solo via HTTPS |
| HttpOnly | Non accessibile via JavaScript (previene furto via XSS) |
| SameSite=Strict | Non inviato in richieste cross-site (previene CSRF) |
5. Aggiornare tutto
Il 60% delle violazioni sfrutta vulnerabilità note per le quali esiste già una patch.
Checklist aggiornamenti:
- [ ] CMS aggiornato all'ultima versione (WordPress, Joomla, Drupal)
- [ ] Plugin e temi aggiornati
- [ ] Dipendenze npm/composer aggiornate (
npm audit) - [ ] Server web aggiornato (Nginx, Apache)
- [ ] PHP/Node.js/Python alla versione supportata
- [ ] Sistema operativo del server con patch di sicurezza
6. Validare tutti gli input
Non fidatevi mai dei dati che ricevete dagli utenti. Validazione lato server obbligatoria.
import { z } from 'zod'
const contattoSchema = z.object({
nome: z.string().min(1).max(100),
email: z.string().email(),
messaggio: z.string().min(10).max(5000),
})
// Validare PRIMA di qualsiasi operazione
const risultato = contattoSchema.safeParse(req.body)
if (!risultato.success) {
return res.status(400).json({ errore: 'Dati non validi' })
}
7. Implementare la rate limiting
Proteggete gli endpoint sensibili dal brute force e dagli abusi.
Endpoint da proteggere in priorità:
- Login / registrazione
- Reset password
- Form di contatto
- API pubbliche
- Endpoint di pagamento
8. Configurare i backup automatici
Un backup non testato è un backup che non esiste.
Regola 3-2-1:
- 3 copie dei dati
- 2 supporti di memorizzazione diversi
- 1 copia off-site (cloud, altro data center)
Frequenza consigliata:
- Database: giornaliero
- File: settimanale
- Configurazioni: ad ogni modifica
Test: ripristinate un backup almeno una volta al trimestre.
9. Monitorare gli accessi
Non potete proteggere ciò che non monitorate.
Cosa monitorare:
- Tentativi di login falliti (> 5 in 10 minuti = allarme)
- Accessi amministrativi
- Modifiche ai file critici
- Errori 500 anomali
- Richieste a percorsi sospetti (
/wp-admin,/phpmyadmin,/.env)
10. Scansionare regolarmente
Un audit di sicurezza non è un evento unico — è un processo continuo.
Frequenza consigliata: | Tipo di scansione | Frequenza | |-------------------|-----------| | Scansione vulnerabilità automatizzata | Settimanale | | Verifica certificato SSL | Mensile | | Audit header di sicurezza | Mensile | | Test di penetrazione | Semestrale/Annuale | | Revisione degli accessi | Trimestrale |
Bonus: checklist rapida di verifica
Dopo aver implementato i 10 passi, verificate:
- [ ] HTTPS attivo su tutte le pagine
- [ ] Header di sicurezza configurati (testate su securityheaders.com)
- [ ] CSP implementata e funzionante
- [ ] Cookie con flag Secure, HttpOnly, SameSite
- [ ] Nessuna dipendenza con vulnerabilità note
- [ ] Input validati lato server
- [ ] Rate limiting attivo sugli endpoint sensibili
- [ ] Backup automatici configurati e testati
- [ ] Monitoraggio degli accessi attivo
- [ ] Scansione periodica programmata
Conformità normativa in Italia
Implementare questi 10 passi non è solo una buona pratica tecnica — è anche un passo concreto verso la conformità alle normative italiane ed europee. La Direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, richiede alle organizzazioni nei settori essenziali e importanti di adottare misure tecniche e organizzative adeguate. L'ACN (Agenzia per la Cybersicurezza Nazionale) supervisiona l'attuazione e può imporre sanzioni fino a 10 milioni di euro per le inadempienze più gravi.
Per le aziende che trattano dati personali, il GDPR (art. 32) impone misure di sicurezza proporzionate al rischio. In caso di violazione dei dati, il Garante Privacy valuta se l'organizzazione aveva adottato misure tecniche adeguate — HTTPS, header di sicurezza, validazione degli input e monitoraggio rientrano tra i controlli attesi.
Le Pubbliche Amministrazioni devono inoltre rispettare le Misure Minime di Sicurezza ICT dell'AgID, che includono esplicitamente molte delle azioni descritte in questa guida.
Conclusione
La sicurezza web non è un progetto con una data di fine — è un'abitudine quotidiana. Questi 10 passi coprono l'80% dei vettori di attacco più comuni. Iniziate oggi e rendete il vostro sito un bersaglio più difficile.
Scansiona il tuo sito web gratis con WarDek — OWASP, NIS2, GDPR, AI Act in un'unica scansione.