Programmi automatici cercano i punti deboli del tuo sito prima che arrivi un cliente

Chi apre un sito per la propria attività pensa spesso di essere troppo piccolo per interessare a qualcuno. Il ragionamento si capisce. Parte però da un’idea sbagliata di come funzionano gli attacchi. Negli attacchi di massa nessuno sceglie le vittime a mano. Programmi automatici provano un indirizzo dopo l’altro e chiedono sempre le stesse cose, nella speranza che da qualche parte arrivi la risposta giusta. Del fatturato di chi sta dall’altra parte non sanno nulla. Non gli serve.

Lo si vede bene nei registri di questo sito, dove una parte delle richieste arriva all’indirizzo numerico del server, senza il nome del sito. Chi le manda non sa cosa ci sia su quella macchina e passa in rassegna indirizzi, uno dopo l’altro, senza sapere nemmeno se a quello di turno risponda un sito, un gestionale o nulla. Quanto il sito sia conosciuto, o da quanto tempo sia online, per lui è indifferente.

Quattro settimane di richieste, contate una per una

I numeri che seguono vengono dal proxy di questo sito, il programma che riceve ogni richiesta e decide se passarla al sito, e coprono 28 giorni, dal 16 agosto al 12 settembre 2026. Si contano due tipi di richieste. Il primo tipo comprende le richieste arrivate in chiaro, senza cifratura, che non portano il nome di un sito ospitato qui, come quelle dirette all’indirizzo numerico del server o con un nome estraneo. Quelle in chiaro con il nome del sito ricevono solo un rinvio alla versione cifrata. Restano fuori, salvo che rientrino nel secondo tipo. Nel secondo rientrano i tentativi mirati, cioè le richieste verso percorsi o con metodi compresi in un elenco scritto prima di contare, come file di configurazione, pannelli di amministrazione e pagine di programmi che il sito non usa. Una richiesta che rientra in tutti e due i tipi vale una volta. Si contano le righe del registro. Un tentativo che segue un rinvio, quindi, compare due volte.

In tutto sono 32.897 richieste, da 1.901 indirizzi diversi. Nessuna ha ottenuto una risposta positiva. L’87 per cento è stato rifiutato. Le altre hanno ricevuto un rinvio all’indirizzo corretto, una pagina inesistente, un errore o la chiusura della connessione.

Il ritmo non è costante, perché il giorno più calmo, il 29 agosto, ne ha portate 240 e il più intenso, il 7 settembre, 3.032, mentre in metà dei giorni sono rimaste sotto le 876. Arrivano a ondate. Cosa le faccia partire, dai registri non si capisce.

Chi le manda? Dei 1.901 indirizzi, almeno 1.199 appartengono a reti di centri dati, cioè a server noleggiati, riconoscibili dal nome dell’operatore. 6 sono riconoscibili come reti domestiche o mobili. Gli altri restano non classificati. A volte il nome della rete non basta a capirlo, a volte nel database manca.

Un limite va detto. Il registro dice cosa ha risposto il proxy a ciascuna richiesta, ma non dimostra che il sito sia privo di difetti e non vede i tentativi che passano per altre strade.

Cosa cercano

I tentativi mirati sono 25.049 e si lasciano raggruppare per quello che chiedono. Il gruppo più grande, il 72,9 per cento, riguarda segreti e configurazioni, cioè i file in cui un’applicazione tiene password, chiavi d’accesso ai servizi esterni, indirizzi e credenziali dei database.

Il percorso chiesto più spesso è /.env, il nome abituale di uno di questi file, 469 volte da 141 indirizzi. E non si fermano lì. Tra i percorsi cercati ce ne sono 2.156 diversi che contengono .env, compreso /.env stesso, e gli altri aggiungono suffissi o sottocartelle, come /.env.bak, /.env.local, /api/.env e /backend/.env, perché il file può essere stato lasciato in posti diversi. Chi trova un file del genere raggiungibile da fuori non deve forzare nulla. Ha già le chiavi.

Poi c’è il software che qui manca. Questo sito non usa WordPress e non esegue PHP, eppure il terzo percorso più richiesto è /wp-admin/install.php, la pagina con cui si installa WordPress, 270 volte da 61 indirizzi. Mettendo insieme le richieste per WordPress, PHP, pannelli di amministrazione e altri programmi assenti si arriva a 6.214, il 24,8 per cento dei tentativi mirati.

Quelli pensati per la tecnologia con cui il sito è costruito sono stati 345, l’1,4 per cento. I numeri fanno pensare che la gran parte di questi programmi non controlli cosa c’è dall’altra parte e provi quello che in giro si trova più spesso.

Perché proprio WordPress e le piattaforme già pronte

WordPress e le piattaforme simili fanno girare una parte enorme dei siti, e già questo le rende il primo tentativo. C’è anche una ragione più tecnica.

Queste piattaforme si allargano con componenti aggiuntivi scritti da terzi, i plugin, e Patchstack ha contato 7.966 nuove falle nell’ecosistema WordPress nel 2024, il 34 per cento in più dell’anno prima, e il 96 per cento stava nei plugin, mentre nel nucleo di WordPress ne sono state trovate solo sette. Per sfruttarne il 43 per cento non serviva nemmeno un accesso.

Sucuri, che ripulisce siti violati, nel rapporto sul 2022 attribuiva a WordPress il 96,2 per cento delle infezioni tra le piattaforme di gestione dei contenuti che aveva trattato. Su quel numero pesa anche quanto WordPress è diffuso. Quanto a come iniziano le violazioni in generale, l’edizione 2026 del rapporto annuale di Verizon indica che il 31 per cento parte da una falla nel software, più di quelle che partono da password rubate.

Su misura non vuol dire sicuro per definizione

Sarebbe comodo concludere che basta cambiare tecnologia. Un sito scritto su misura non è protetto per il fatto di esserlo, e vale quanto il lavoro di chi lo ha fatto.

Quello che cambia è quanto il sito espone. Un sito su misura non si porta dietro decine di componenti altrui da tenere aggiornati e non ha una pagina di amministrazione all’indirizzo che hanno milioni di altri siti, che è il primo che i programmi provano. Una falla in un plugin diffuso non lo tocca, mentre quelle del framework su cui è costruito lo riguardano e si chiudono aggiornandolo in fretta. Le porte sono meno, e sono quelle decise da chi ha scritto il sito.

Nei registri di questo sito, poco meno di un quarto dei tentativi mirati cercava programmi che qui non ci sono. Il resto va gestito comunque. Vuol dire che i file di configurazione non devono essere raggiungibili da fuori, che un indirizzo bloccato deve restare bloccato e che la risposta a una richiesta sospetta va stabilita in anticipo invece di lasciarla al comportamento predefinito del server.

Affidare la protezione a una lunga fila di componenti scritti da altri somiglia a montare lucchetti su una porta di cui non si conoscono i cardini. In un sito progettato con cura, chi può entrare, cosa può vedere e dove finiscono i dati si decidono mentre lo si costruisce.

Una scelta da fare prima di andare online

Le richieste all’indirizzo numerico spiegano perché conta il momento. Per mandarle non serve sapere quale sito ci sia sul server, e le stesse richieste arriverebbero a un sito pubblicato ieri, senza visite e senza clienti. Aspettare di avere successo per occuparsi della sicurezza lascia scoperto proprio il periodo in cui nessuno guarda.

Dietro un sito violato di solito c’è qualcosa di preciso, un file rimasto raggiungibile, un componente non aggiornato, una pagina di amministrazione aperta a tutti. I segni si notano tardi, quando le pagine risultano modificate, la posta si riempie di richieste finte o compare un avviso di Google tra i risultati di ricerca. A quel punto i dati possono essere già usciti, e rimettere ordine costa molto più che impostare bene le cose all’inizio.

Farlo subito non richiede grandi spese. Si tratta di poche decisioni da prendere mentre il sito si costruisce, che se rimandate diventano lavori di recupero su un sito già in funzione.

Da dove partire

Se il sito è in costruzione, o esiste già e non si sa quanto sia esposto, conviene cominciare guardando cosa risponde oggi a chi lo interroga da fuori. Una verifica di sicurezza parte da lì. Si chiude con l’elenco delle cose da sistemare, in ordine di importanza.

Richiedi una verifica di sicurezza del tuo sito

Le fonti

I numeri su questo sito vengono dai registri del suo proxy, contati con definizioni scritte prima del conteggio e confermati da un secondo conteggio indipendente. Le fonti esterne sono state ricontrollate il 13 settembre 2026.

Patchstack, State of WordPress Security in 2025 (falle del 2024 nei plugin)

Sucuri, rapporto sui siti violati nel 2022 (quota di WordPress tra le infezioni)

Verizon, Data Breach Investigations Report 2026 (come iniziano le violazioni)