Contenuto violato: cosa succede davvero quando a essere compromesso e' il sito stesso, non un inserzionista

Il primo segnale raramente arriva da qualcuno di ufficiale. Sono alcuni indirizzi strani in Search Console che nessuno del team ricorda di aver creato, oppure il traffico organico che scende senza una causa visibile nei soliti pannelli, o un inserzionista che scrive per chiedere perche' la pagina del suo annuncio reindirizza verso qualcosa che non ha niente a che fare con il sito. A volte e' un visitatore che segnala che il browser si e' rifiutato di aprire la pagina. Niente di tutto questo assomiglia a una frode di un inserzionista, e niente assomiglia al caso dell'annuncio malevolo che fa marchiare un sito senza che il suo codice c'entri qualcosa.

Questo e' l'altro caso, ed e' un problema diverso con una soluzione diversa. Qui qualcosa e' stato davvero aggiunto ai file o al database del sito senza che nessuno del team lo avesse messo li'. Un sito di annunci in questa categoria non puo' permettersi di sembrare inaffidabile nemmeno per una settimana: non per Google, non per un processore di pagamenti che tratta gia' il settore come piu' rischioso della media, non per un host che potrebbe gia' essere a un reclamo di distanza dalla sospensione dell'account. Sapere esattamente cos'e' successo, cosa controlla davvero Google e in quale ordine funziona davvero la soluzione vale di piu' qui di quanto varrebbe per il blog di una piccola impresa qualunque, perche' il costo di sbagliare l'ordine e' piu' alto.

Come entra davvero un attaccante, e raramente e' qualcosa di eclatante

A questo livello quasi nessuno prende di mira specificamente un sito di annunci per adulti. Lo schema piu' comune e' un bot che setaccia il web aperto cercando qualunque sito che usi un certo software con una falla nota e non corretta, allo stesso modo in cui setaccia i siti di ristoranti o i blog di studi legali. Il sito viene colpito perche' usa lo stesso CMS, lo stesso plugin o la stessa libreria non aggiornata di un milione di altri siti, non perche' qualcuno lo abbia osservato e deciso che valeva lo sforzo.

Il software non aggiornato e' un fattore reale e comune, ma non e' tutta la storia, e trattarlo come se lo fosse lascia scoperta meta' dei punti d'ingresso reali. Il report sui siti violati di Sucuri, relativo ai siti ripuliti nel 2023, ha trovato che il 39,1% delle installazioni CMS compromesse eseguiva software non aggiornato al momento dell'infezione, in calo dal 50,58% dell'anno precedente. Lo stesso report ha trovato che solo circa il 14% di quei siti aveva ancora un plugin o un tema vulnerabile identificabile una volta che Sucuri aveva esaminato da vicino la bonifica. In altre parole, la maggior parte dei siti ripuliti non era stata violata davvero attraverso la falla software che un operatore si aspetterebbe di dover correggere per prima.

L'altra meta' del quadro sono le credenziali. Il Data Breach Investigations Report 2025 di Verizon, che guarda a ogni settore che monitora e non ai soli siti web, ha trovato le credenziali rubate o indovinate leggermente davanti alle vulnerabilita' software sfruttate come modo in cui gli attaccanti ottengono il primo accesso: 22% delle violazioni contro il 20%. Non e' un numero costruito solo sui siti di annunci, ma coincide con cio' che Sucuri osserva nelle bonifiche specifiche per le piattaforme CMS. Una password amministrativa riutilizzata da un account email personale finito in una violazione non collegata anni prima e', nella pratica, una via d'accesso probabile quanto un plugin non aggiornato.

La conseguenza pratica e' che mettere in sicurezza un sito e' un lavoro su due fronti di peso pressoche' uguale, non uno solo. Un calendario di aggiornamenti chiude meta' dei varchi software. Una disciplina separata su chi ha un accesso, qual e' davvero la sua password e se viene riutilizzata altrove chiude l'altra meta'. Un operatore che si limita ad aggiornare i plugin ha fatto meta' del lavoro e potrebbe non accorgersene mai, perche' la schermata di avviso appare identica indipendentemente da quale meta' sia stata saltata.

Come lo chiama davvero Google, e perche' e' un problema diverso da un annuncio malevolo

Un diverso tipo di avviso di Chrome e' gia' stato trattato qui: quello in cui una rete pubblicitaria sotto contratto serve una creativita' ingannevole o malevola attraverso gli stessi spazi pubblicitari del sito, e Google marchia il sito per un contenuto che non ha mai toccato. Questo non e' quel caso. Qui qualcosa e' stato aggiunto alle pagine o al database del sito senza che l'operatore lo sapesse, ed e' esattamente cio' che le norme antispam di Google definiscono contenuto violato: contenuto inserito in un sito senza il permesso del proprietario, a causa di una debolezza nella sicurezza del sito stesso.

La documentazione di Google distingue tre schemi precisi. L'iniezione di codice e' codice malevolo, di solito JavaScript, inserito direttamente in pagine o iframe gia' esistenti. L'iniezione di pagine sono pagine nuove aggiunte al sito che prima non c'erano, costruite per manipolare il posizionamento nei motori di ricerca o per condurre un tentativo di phishing, mentre le pagine che un visitatore gia' conosceva spesso non mostrano alcun segno visibile che qualcosa non vada. L'iniezione di contenuto e' ancora piu' sottile: testo o link nascosti aggiunti alle pagine esistenti tramite trucchi CSS o HTML, visibili al crawler di un motore di ricerca ma non a una persona che guarda la stessa pagina nel browser.

L'iniezione di pagine e' di solito lo schema che gli operatori scoprono per ultimo, ed e' utile capire perche' un attaccante si prenda il disturbo invece di costruire semplicemente un sito usa e getta tutto suo. Un dominio che ha gia' una storia, backlink esistenti e una posizione consolidata nei risultati di ricerca fa riciclare contenuto spam nel posizionamento molto piu' in fretta di quanto farebbe un dominio nuovo di zecca, quindi gli attaccanti preferiscono prendere in prestito la reputazione di un sito esistente piuttosto che costruirsene una da zero. E' un meccanismo diverso da l'attacco esterno a base di link trattato altrove: li', l'attacco punta link di altri siti verso il bersaglio dall'esterno; qui, le pagine spam sono costruite per vivere sul dominio stesso del bersaglio, dentro la sua stessa struttura di file.

Una volta che quel contenuto esiste sul sito, le conseguenze si accumulano. Il report Problemi di sicurezza di Search Console segnala direttamente la proprieta', alcune pagine possono essere escluse dai risultati o sostituite con un avviso nell'elenco, e il Safe Browsing di Chrome puo' iniziare a mostrare ai visitatori la stessa schermata rossa interstiziale gia' descritta per il caso della rete pubblicitaria, questa volta innescata dal fatto che il sito ospita davvero contenuto malevolo o ingannevole, non da una creativita' difettosa che vi transita.

Far togliere l'avviso: l'ordine che funziona davvero

Le indicazioni di Google sono precise sull'ordine, e la maggior parte del tempo perso nella pratica deriva dal fare questi passaggi fuori sequenza. Il primo compito e' trovare e rimuovere ogni istanza del contenuto iniettato, non solo la pagina campione che Search Console ha citato come esempio del problema. Quell'indirizzo e' un campione, non un inventario, e una bonifica che si ferma dopo averlo sistemato di solito lascia in piedi la maggior parte dell'iniezione vera e propria.

Il secondo compito e' scoprire come l'attaccante sia entrato e chiudere esattamente quel varco, che fosse un plugin non aggiornato, una credenziale trapelata o un permesso mal configurato, perche' cancellare le pagine spam senza correggere il punto d'ingresso azzera semplicemente l'orologio finche' lo stesso attaccante, o la stessa scansione automatica, non torna dalla stessa porta. La documentazione di Google e' esplicita sul fatto che la correzione deve coprire l'intero sito, non solo la homepage o la pagina che un visitatore ha segnalato, e una parte collegata della stessa guida raccomanda di cambiare ogni password collegata a un account con accesso amministrativo: il login del CMS, il pannello di controllo dell'hosting, FTP o SFTP, e il database, proprio perche' il punto d'ingresso e' spesso uno di questi e non la pagina dove e' comparso il sintomo.

La parte che gli operatori sbagliano piu' spesso e' quando chiedere a Google di controllare di nuovo. Chiedere una revisione prima che la bonifica sopra descritta sia davvero completata non accelera nulla; Google afferma chiaramente che chiedere una revisione mentre il problema esiste ancora prolunga soltanto il tempo in cui il sito resta marchiato. I tempi di revisione variano per categoria: una revisione per malware semplice richiede di solito pochi giorni, una revisione per phishing circa un giorno, ma una revisione di contenuto violato che include pagine spam iniettate puo' richiedere fino a diverse settimane, perche' Google tratta questa categoria come una che potrebbe richiedere un controllo davvero manuale invece di un ricontrollo automatico.

Un secondo episodio dello stesso avviso dopo che una revisione e' gia' passata e' di solito un segnale che il punto d'ingresso non era mai stato davvero chiuso la prima volta, solo il sintomo. Cancellare le pagine spam visibili sembra concludere il lavoro, ma se il plugin vulnerabile e' ancora li' o la password trapelata funziona ancora, lo stesso varco viene riutilizzato, a volte entro pochi giorni dalla rimozione dell'avviso.

Cosa previene davvero tutto questo, con un budget che questa attivita' puo' sostenere

Niente di tutto questo richiede di assumere un team di sicurezza dedicato, e gli operatori che saltano le basi di solito lo fanno perche' l'elenco sembra piu' lungo di quanto sia davvero. Il CMS, il suo tema e ogni plugin installato hanno bisogno di un calendario di aggiornamento fisso, controllato ogni settimana invece che "quando c'e' tempo", e tutto cio' che e' stato installato una volta e non viene piu' usato andrebbe rimosso del tutto invece di lasciato dormiente, perche' un plugin inattivo resta comunque una porta mai chiusa a chiave.

La disciplina sulle credenziali pesa quanto gli aggiornamenti, visto cosa mostrano davvero i numeri di Sucuri e Verizon citati sopra. Significa una password unica per ogni account che puo' toccare il sito, generata e conservata in un gestore di password invece che a memoria, autenticazione a due fattori attiva su ogni accesso che la offre, e nessun login condiviso passato tra staff o moderatori, visto che un login condiviso e' anche un accesso che nessuno puo' ricondurre a una persona precisa quando qualcosa va storto.

I backup contano quanto la prevenzione, perche' sono cio' che riporta un sito online in poche ore invece di aspettare una revisione di Google che puo' durare settimane. Un backup che vive sullo stesso account di hosting del sito che dovrebbe proteggere non e' un gran backup, perche' un attaccante con accesso amministrativo di solito puo' raggiungere anche quello; una copia conservata altrove, e davvero testata ripristinandola almeno una volta invece di lasciata girare senza verifica, e' la differenza tra una settimana brutta e un mese brutto.

L'ultimo elemento e' semplicemente scoprirlo presto. Gli avvisi via email di Search Console fanno arrivare il report Problemi di sicurezza in una casella di posta che qualcuno legge davvero, invece che far scoprire all'operatore il problema dal reclamo di un visitatore o da un'emorragia lenta di traffico organico giorni o settimane dopo i fatti. Nessuno di questi passaggi costa piu' del tempo, e tutti costano meno fatti adesso che dopo che la schermata di avviso ha gia' bruciato una settimana di traffico mentre la bonifica viene sistemata.

L'ordine, se l'avviso e' gia' comparso, e' ripulire tutto per primo, chiudere il varco specifico che lo ha permesso, e solo allora chiedere a Google di controllare di nuovo, mai il contrario. L'ordine, se non e' ancora successo niente, e' fare comunque le stesse quattro cose su un calendario questa settimana: aggiornare cio' che e' installato, cambiare ogni password con accesso amministrativo, attivare l'autenticazione a due fattori ovunque sia offerta, e testare un vero ripristino da backup. In entrambi i casi, la soluzione non e' mai stata una questione della giurisdizione sul certificato o delle dimensioni dello studio legale sotto contratto: e' una questione di chi puo' accedere, di quanto sia aggiornato il software, e di se qualcuno se ne accorgerebbe in tempo.