How we protect this site

This page is written to be understandable for everyone. Technical terms are explained in plain words. If you want the precise technical details, each section links to the internal project documentation.

1. Why we care

Un sito istituzionale è un bersaglio costante: ogni minuto, in qualunque parte del mondo, ci sono programmi automatici che scansionano migliaia di siti cercando porte di ingresso aperte, password deboli, plugin con bug noti, form da inondare di spam. Il 99% degli attacchi non è "personale": è statistica. Per questo non basta un antivirus o una password complicata — servono più strati di protezione che lavorino insieme.

Abbiamo costruito 12 livelli di difesa indipendenti. Se uno fallisce, gli altri tengono. Se un giorno un attaccante riuscisse a superarne tre, dovrebbe ancora superare i restanti nove per fare danni reali. Si chiama "difesa in profondità" — la stessa filosofia di un castello medievale: fossato, mura esterne, mura interne, torre principale, e infine la sala del trono.

2. Cloudflare: the shield in front of the site

Quando visiti questo sito, non parli direttamente con il nostro server. Parli prima con Cloudflare — un'azienda che gestisce circa il 20% del traffico web mondiale, con 300+ data center in tutto il mondo (uno è a Milano, il più vicino a noi). Cloudflare è un "filtro intelligente" che si mette in mezzo: legge ogni richiesta che arriva al sito, decide se è legittima e solo allora la lascia passare.

What Cloudflare blocks

• DDoS attacks: quando migliaia di computer (botnet) tentano contemporaneamente di sovraccaricare il sito per metterlo offline. Cloudflare ne assorbe il traffico ai loro data center prima che arrivi a noi. È una protezione "illimitata" — sostengono attacchi da centinaia di gigabit al secondo.
• Malicious bots: automatic scanners that look for flaws. Cloudflare recognises them from their behaviour and blocks them. Legitimate bots (Google, Bing to index the site) pass normally.
• Known attack patterns: SQL injection, cross-site scripting, tentativi di inserire codice malevolo nei form. Cloudflare ha un firewall applicativo (WAF) che riconosce centinaia di tipi di attacco e li ferma all'origine.

Bonus: the site is also faster

Cloudflare non è solo difesa. Tiene una copia delle parti "statiche" del sito (immagini, CSS, font) ai loro 300 data center sparsi per il mondo: chi visita il sito da Milano lo riceve dai server di Milano, non dai nostri server in Italia centrale. Risultato: caricamento più rapido + meno carico sui nostri server.

3. HTTPS always — the lock on the connection

When you see the green lock in the browser address bar, it means that the communication between your device and the site is encrypted: no one (not even the WiFi manager of the bar where you are) can read what you write in forms or which pages you visit.

Il certificato che garantisce questa cifratura è emesso gratuitamente da Let's Encrypt (un'autorità non-profit riconosciuta da tutti i browser) e si rinnova automaticamente ogni 90 giorni. La connessione usa standard moderni: TLS 1.2 minimo, TLS 1.3 preferito, HTTP/3 dove supportato. Il test indipendente di SSL Labs ci dà voto A+ (il massimo).

Inoltre, abbiamo abilitato HSTS — una direttiva che dice al tuo browser: "per i prossimi 12 mesi non provare nemmeno a contattarmi senza HTTPS". Questo blocca certi attacchi sofisticati che potrebbero forzare una connessione non cifrata.

4. Il nostro server è invisibile dall'esterno

The physical server hosting WordPress is on Google Cloud, in a Milan data centre. But if you try to contact it directly (by its IP address) — it does not respond. The cloud firewall is configured to accept connections only from Cloudflare data centres. All others are rejected.

Perché è importante? Se il nostro server fosse raggiungibile direttamente, un attaccante che ne scopre l'indirizzo IP potrebbe bypassare Cloudflare — ignorare il filtro intelligente e attaccare il server senza protezione. Chiudendo il server "dietro" Cloudflare, l'unica strada per arrivarci passa per il filtro.

5. Administrator access: triple lock

Only a few people are allowed to modify the site (upload new stories, events, photos). For them we have three cascading protections:

1. Secret login URL: la pagina di accesso non si trova all'indirizzo standard di WordPress (che tutti conoscono e attaccano in continuazione). Si trova a un indirizzo segreto, conosciuto solo dagli amministratori.
2. Attempt limit: dopo 5 tentativi falliti di password in 10 minuti, l'indirizzo IP viene bannato per 1 ora. Niente brute-force possibile.
3. Two-factor authentication (2FA): per entrare non basta la password — serve anche un codice di 6 cifre generato sul telefono dell'amministratore (con app come Google Authenticator). Anche se qualcuno rubasse la password, senza il telefono non può entrare.

In più: l'utente "admin" classico — il primo bersaglio di ogni tentativo di hacking — è stato eliminato. Tutti gli amministratori hanno username personali non prevedibili.

6. Automatic updates (within 24 hours)

WordPress, the plugins and all site components receive security updates whenever vulnerabilities are discovered (this is normal: it happens with every software). The problem, on many sites, is that these updates are only applied when someone remembers to do it — sometimes weeks later. Meanwhile, attackers have already developed exploits for the published flaws.

Su questo sito gli aggiornamenti di sicurezza si installano da soli, automaticamente, di solito entro 24 ore dalla pubblicazione. Riguardano solo le patch di sicurezza ("minor releases"): gli aggiornamenti maggiori, che potrebbero introdurre incompatibilità, restano controllati a mano.

7. File sentinel: webshell detection

Ogni notte alle 4:30 un controllo automatico calcola un'"impronta digitale" (hash crittografico SHA-256) di tutti i 1.373 file critici del sito: il codice di WordPress, i plugin, il tema. Confronta queste impronte con un riferimento salvato il giorno prima. Se anche un solo file è diverso, riceviamo immediatamente un'email.

A cosa serve? Se un attaccante riuscisse a infilare un file malevolo (chiamato "webshell" — un mini-pannello di controllo che permette di eseguire comandi sul server), il giorno dopo ce ne accorgiamo. Senza questo controllo, una webshell può rimanere nascosta per mesi.

In più, il server PHP è configurato per non poter eseguire comandi di sistema (le funzioni "shell_exec", "system", "exec" sono disabilitate). Anche se un attaccante riuscisse a piazzare una webshell, questa non potrebbe fare nulla — è una pistola scarica.

8. WAF: the bouncer that checks every request

WAF sta per "Web Application Firewall" — letteralmente, un firewall specializzato per applicazioni web. Pensa al buttafuori di una discoteca: legge ogni richiesta che arriva al sito (cosa stai chiedendo, da dove vieni, con quale "vestito"), confronta con una lista di pattern sospetti, e decide se farti passare o sbatterti fuori. Il tutto in millisecondi, automaticamente.

We have two WAFs working together

• Cloudflare WAF (all'edge): il primo a vedere le richieste. Include il "Managed Ruleset" — un set di regole curato da Cloudflare e aggiornato in continuo da chi monitora gli attacchi di tutto il mondo. Conosce migliaia di pattern di SQL injection, cross-site scripting, command injection, path traversal, ecc. Le richieste sospette le blocca senza arrivare al server.
• AIOS (on the server): a second firewall specific to WordPress, running on the server. It knows the specific fragilities of WP and plugins, blocks attempts to access reserved files (e.g. /wp-config.php), and analyses attack patterns dedicated to CMS.

I due si completano: se un nuovo tipo di attacco non è ancora nelle regole di CF (ad esempio una "zero day" appena uscita), AIOS potrebbe ancora bloccarlo grazie alle sue regole locali. E viceversa.

9. Security headers: rules enforced by the browser

Ogni volta che il sito risponde a una richiesta, manda non solo il contenuto della pagina ma anche un set di "istruzioni" al browser (Chrome, Firefox, Safari) — chiamate header HTTP. Alcuni di questi header sono dedicati alla sicurezza: dicono al browser quali cose è autorizzato a fare con il contenuto della pagina. Sono come le regole della casa che dai a un ospite.

Which headers we have activated

• HSTS (Strict-Transport-Security): "Per i prossimi 12 mesi non parlare mai con questo sito in modo non cifrato, nemmeno se sembra venire da lui". Blocca downgrade attacks.
• X-Frame-Options: "Nessun altro sito può inglobare le nostre pagine in un iframe nascosto". Blocca il clickjacking — un attacco in cui ti fanno cliccare su qualcosa pensando sia un sito amico.
• X-Content-Type-Options: nosniff: "Fidati di quello che ti dico io sul tipo di file, non provare a indovinarlo". Blocca attacchi che caricano un file finto-immagine ma in realtà è codice JavaScript.
• Referrer-Policy: "Quando il visitatore lascia il sito, non rivelare l'URL completo da cui veniva". Protegge la privacy nella navigazione.
• Permissions-Policy: "Nessuna pagina di questo sito può attivare microfono, fotocamera, USB, pagamenti, accelerometro, ecc.". Limita ciò che JavaScript può chiedere al browser.
• Cross-Origin-Opener-Policy / Cross-Origin-Resource-Policy: isolano le finestre del browser e impediscono ad altri siti di "leggere" i nostri contenuti. Mitigazione per gli attacchi tipo Spectre.

CSP — l'header più potente di tutti

"Content Security Policy" è una sorta di "vetro antiproiettile" per la pagina. Dice al browser esattamente quali sono le sorgenti autorizzate a far girare codice JavaScript, caricare immagini, font, video. Se un attaccante riesce a iniettare codice malevolo nella pagina (ad esempio sfruttando una vulnerabilità XSS — vedi sotto), quel codice arriva al browser ma viene RIFIUTATO perché non è in lista bianca.

Configurare una CSP "stretta" su un sito WordPress complesso (con Yoast SEO, Site Kit, Optimole, mappe Leaflet, Google Tag Manager, Polylang…) richiede di catalogare tutte le sorgenti legittime. La CSP è attiva in modalità report-only: raccogliamo le violazioni tecniche, correggiamo le sorgenti legittime mancanti e passeremo all'enforcement solo dopo un periodo di osservazione adeguato. Nel frattempo gli altri header sopra coprono già molti scenari di XSS.

10. The 4 classic attack classes (and how we defend)

There are hundreds of types of attacks against a website, but 90% fall into 4 well-known families (OWASP Top 10). For each we have multiple overlapping defences:

XSS — Cross-Site Scripting

Cos'è: l'attaccante riesce a inserire codice JavaScript malevolo in una pagina che vedrai tu. Quel codice gira nel tuo browser come se fosse del sito stesso → può rubare i tuoi cookie di sessione, fare azioni a tuo nome, redirect a siti malevoli.

How we defend: (1) WordPress sanitizza automaticamente tutto quello che viene salvato nel database (escape HTML); (2) il nostro tema usa "wp_kses_post()" e "esc_html()" su ogni output dinamico; (3) il WAF di Cloudflare blocca i pattern XSS più comuni nelle URL; (4) la CSP in report-only ci aiuta a individuare violazioni reali prima del passaggio all'enforcement.

SQL Injection

Cos'è: l'attaccante manda input al sito (in un form o nell'URL) che contiene frammenti di codice SQL. Se il sito non li sanitizza, l'attaccante può leggere il database (rubare email, hash di password) o modificarlo.

How we defend: WordPress usa "prepared statements" — query SQL dove i dati utente sono SEPARATI dal codice SQL, quindi non possono influenzare la struttura della query. È protezione nativa. In più il WAF Cloudflare riconosce i pattern SQL injection più comuni e li blocca prima ancora che arrivino al sito.

CSRF — Cross-Site Request Forgery

Cos'è: you are logged in as admin on the site. An attacker makes you visit a malicious page that, on the sly, sends a request to our site to delete an article or create a new user. The browser automatically sends your session cookies, and the site executes the command thinking it comes from you.

How we defend: WordPress usa i "nonce" — token monouso generati per ogni azione amministrativa, validi per pochi secondi e legati alla tua sessione. Una richiesta che arriva da un sito esterno non ha il nonce giusto e viene rifiutata. In più i cookie di sessione hanno l'attributo "SameSite=Lax" che impedisce al browser di mandarli con richieste cross-site.

Brute force su login

Cos'è: l'attaccante prova milioni di combinazioni di password automatiche, sperando di indovinarne una.

How we defend: see section 5 (Administrator access). In summary: secret login URL + 5 attempts/10 minutes then ban + 2FA with code from phone.

11. Anti-snooping: no one must discover who the admins are

WordPress, di default, ha una caratteristica sorprendentemente generosa con gli attaccanti: chiunque può chiedere "dammi la lista degli utenti registrati" e ricevere nome utente, foto profilo, descrizione bio. Si chiama "user enumeration". Per un attaccante è oro: dimezza la difficoltà di un brute-force, perché invece di indovinare USERNAME + PASSWORD deve indovinare solo la password.

Ci sono 3 modi standard per fare user enumeration su WordPress, e li abbiamo bloccati TUTTI con il nostro plugin custom "justbit-wp-security":

• ?author=1, ?author=2, ...: WordPress automatically redirects to /author/{username}/ revealing the username. We now return 404.
• /wp-json/wp/v2/users: l'API REST di default espone la lista utenti. L'abbiamo rimossa dall'endpoint pubblico — ora ritorna 404 se non sei loggato.
• /author/{nome}/: l'archivio degli articoli per autore. Nel nostro caso non serve (gli autori non hanno una pagina pubblica) — bloccato a livello edge da Cloudflare con 404.

In più, le risposte di errore al login sono volutamente generiche ("Credenziali non valide"). Non diciamo "username sbagliato" o "password sbagliata" — quella informazione, ripetuta migliaia di volte, aiuterebbe un attaccante a costruire la lista degli username validi.

12. Off-site nightly backups

Every night at 3am the site performs a full backup: database, uploaded images, plugins. The backup is saved in a separate location (a Google Cloud Storage bucket geographically different from the server) and encrypted. It keeps the history of the last 14 days.

The worst case scenario — if for any reason the site were damaged (attack, human error, hardware failure) — is to revert to the previous night state. Never more than 24 hours of lost content.

13. We know immediately if something is wrong

Un servizio esterno controlla il sito ogni 5 minuti. Se la home non risponde correttamente per più di 1 minuto, parte automaticamente un'email di allerta agli amministratori. Anche alle 3 di notte. Anche di domenica. Anche a Ferragosto.

In addition, all access logs are collected and analysed: if we see anomalous patterns (e.g. the same IP address making 1000 requests in one second) we can intervene before it becomes a problem.

14. Your personal data, in practice

This site collects very little personal data. In detail:

• Navigazione e performance: il sito raccoglie misurazioni tecniche interne su pagine visitate, sessione, dispositivo, performance e, se disponibile dagli header Cloudflare, paese/città approssimativi. Senza consenso usiamo solo identificatori di sessione non persistenti; gli identificatori persistenti e gli strumenti statistici/terzi si attivano solo con consenso.
• Contact form: if you write to us, we receive name, email and message. We keep them only for the time needed to reply, plus 12 months for documentation.
• Cookies: you can always revoke consent and delete them all from the banner at the bottom left.

Full details on how we handle data are in the Privacy Policy and the Cookie Policy.

15. In summary

16. Found a problem? Write to us

If you are a security researcher or notice something strange on the site (unexpected errors, abnormal behaviour, suspected phishing using our name), we appreciate a timely and responsible report.

Scrivi a [email protected] con oggetto "Security disclosure" e una breve descrizione. Ti risponderemo nel più breve tempo possibile e, se confermiamo il problema, ti riconosceremo pubblicamente come scopritore (se lo desideri).

Questa pagina viene aggiornata ogni volta che modifichiamo qualcosa di rilevante nell'infrastruttura di sicurezza. La data in cima riflette l'ultima revisione.