8BitSecurity

Tra gli scenari di cybersecurity in cui siamo soliti imbatterci, difficilmente prenderemmo in considerazione la SEO e i risultati di ricerca di Google. Ma se un attore malintenzionato avesse la facoltà di eliminare dai risultati di ricerca del motore più famoso al mondo tutte le pagine di un’azienda, quali danni economici e di immagine potrebbe causare? È quanto è emerso a fine luglio 2025, quando un’inchiesta ha rivelato una vulnerabilità che consentiva a chiunque, con una tecnica incredibilmente semplice, di de-indicizzare pagine specifiche dai risultati di Google.

La vulnerabilità

Google mette a disposizione un servizio pubblico chiamato Refresh Outdated Content (“Aggiorna contenuto obsoleto”). Serve a non proprietari del sito per chiedere a Google di aggiornare i risultati quando una pagina non esiste più, oppure quando il contenuto mostrato nello snippet non rispecchia la versione attuale (ad esempio perché sono stati rimossi dati sensibili). Il suo scopo è del tutto legittimo ed è quello di mantenere il motore di ricerca aggiornato.

Alcuni attori malevoli, però, hanno scoperto che presentando richieste con varianti dell’URL con lettere maiuscole/minuscole alterate (per esempio cambiando la capitalizzazione dello “slug”) si poteva indurre Google a considerare erroneamente la pagina originale come da rimuovere.

Così facendo, era possibile quindi segnalare una versione “errata” dell’URL che generava 404, e il sistema finiva per de-indicizzare anche la versione vera e funzionante. (404 Media, Freedom of the Press)

La scoperta della vulnerabilità

La Freedom of the Press Foundation (FPF) ha raccontato come un proprio articolo sia sparito da Google nonostante fosse ancora normalmente online. Ogni volta che il pezzo veniva reindicizzato, nuove richieste arrivavano prendendo di mira la stessa pagina con capitalizzazioni diverse della URL: nove richieste contro l’articolo della FPF e 21 contro due articoli del giornalista Jack Poulson, in un arco di settimane. Dopo le segnalazioni, Google ha confermato il problema e dichiarato di aver rilasciato una correzione; un tentativo di abuso del 1° agosto è stato negato, segno che il fix aveva effettivamente risolto la criticità.

Search Engine Journal ha riportato che la falla poteva essere sfruttata per rimuovere persino intere serie di articoli, descrivendo proprio il ruolo della capitalizzazione dell’URL nell’exploit e sottolineando come Google affermi che sia stato colpito solo “una piccola frazione” di siti. (Search Engine Journal)

Perché Google ha uno strumento del genere?

Esistono due “famiglie” di strumenti:

• Refresh Outdated Content (pubblico): pensato per non proprietari, per aggiornare risultati quando una pagina è cambiata o non esiste più. Non dovrebbe rimuovere pagine vive e immutate.
• Search Console → Removals (per proprietari): consente a chi gestisce il sito di nascondere temporaneamente i propri URL e — cosa cruciale — vedere lo storico delle richieste di rimozione pubbliche che coinvolgono il proprio dominio.

Il bug viveva nel modo in cui Google validava le richieste pubbliche in presenza di mai/ minuscole nell’URL. Google ha dichiarato di aver corretto il comportamento; i dettagli tecnici non sono pubblici, ma gli ulteriori tentativi descritti da FPF risultano respinti dopo il fix.

Gli URL sono case sensitive nella parte del path: per Google /ARTICOLO e /articolo sono due URL diverse. Se il tuo server tratta queste varianti come equivalenti, è buona pratica forzare un formato uniforme (di solito minuscolo) per aiutare i motori a capire che si tratta della stessa pagina.

Inoltre, è possibile rafforzare la coerenza indicando la versione preferita con il tag rel=”canonical” e con redirect 301 da varianti non canoniche a quella definitiva.

Consigli per amministratori di siti web

1. Verifica se il tuo sito è stato colpito.
Apri Google Search Console → Index → Removals e verifica la sezione Outdated content. Se vedi una richiesta Approved relativa a una pagina viva, cancellala e poi usa URL Inspection → Request indexing per rimetterla in coda di indicizzazione.

2. Imposta regole di “URL hygiene”.
Anche se Google ha corretto la falla, riduci la superficie d’attacco:

• Forza le minuscole: configura il CMS o il web server (rewrite) per reindirizzare qualsiasi percorso con maiuscole alla versione minuscola.
• Sii coerente con host e protocollo (scegli https e con o senza www e mantienili sempre).
• Usa rel=”canonical” dove esistono varianti tecniche della stessa pagina (parametri, slash finali, UTM).

3. Monitora segnali anomali.
Oltre al traffico organico in analytics, tieni d’occhio:

• Index coverage e Removals in Search Console;
• Cali improvvisi di clic/impression su singole pagine chiave;
• Email o alert automatici settimanali per “pagine principali”.

4. Prepara un piccolo “piano di recovery”.
Se una pagina critica scompare:

• Verifica che risponda HTTP 200 e carichi correttamente;
• Annulla eventuali rimozioni errate e richiedi l’indicizzazione;
• Valuta di aggiornare leggermente il contenuto (anche solo una nota) per stimolare il recrawl;
• Documenta tutto (screenshot, timestamp) e, se serve, coinvolgi il supporto Google.

E gli altri motori di ricerca?

Questo episodio riguarda la visibilità su Google, non l’esistenza dei contenuti. Se qualcosa “sembra sparito” ma pensi che dovrebbe esistere: prova un altro motore (Bing, DuckDuckGo), incolla l’URL diretto se lo hai, usa la ricerca interna del sito o strumenti come Internet Archive.

Conclusione

Nonostante  buona parte del traffico oggigiorno venga generato attraverso i social network, i motori di ricerca ricoprono ancora un ruolo fondamentale nella diffusione di contenuti rilevanti. Nella già fragile scoperta dei contenuti, soprattutto per giornalismo, watchdog e PMI, il rischio è che anche un meccanismo pensato per ripulire risultati obsoleti possa trasformarsi in uno strumento di censura. E così, oltre ai ben noti tentativi di XSS, SQL injection, bruteforce, CVE exploitation, anche la SEO diventa superficie d’attacco per malintenzionati di qualsiasi genere.