PageBreak di Google: l’AI trova 500 XSS, ma le verifica

Un controllo di sicurezza può sembrare convincente e non essere una vulnerabilità. Il 24 settembre 2026 Google ha presentato PageBreak, un agente interno che usa l’AI per cercare falle nelle proprie applicazioni web. Il dato che attira l’attenzione è forte: secondo l’azienda, il sistema ha individuato oltre 500 vulnerabilità di tipo XSS. Il punto utile per chi gestisce un sito in Italia, però, non è copiare uno strumento che Google non offre al pubblico. È capire come distinguere un sospetto da una falla riproducibile.

PageBreak: che cosa ha annunciato Google

Nel resoconto pubblicato il 24 settembre, Google descrive PageBreak come un agente della propria squadra Product Security. Il progetto, avviato come pilota nel novembre 2025, esamina applicazioni proprietarie e usa in prevalenza modelli Gemini. Non è un servizio che un’azienda può attivare sul proprio WordPress: beneficia del codice, dei segnali di traffico e degli strumenti di scansione già presenti nell’infrastruttura Google.

Google riferisce oltre 500 XSS trovati nelle proprie applicazioni. Il numero va letto per quello che è: un risultato dichiarato dall’azienda nel suo perimetro, non una misura indipendente né una previsione di quanti problemi troverebbe l’AI su un altro sito. Lo stesso report precisa che, tra centinaia di applicazioni costruite con framework interni ad alta garanzia, le XSS rilevate al 4 settembre erano soltanto due, entrambe legate a endpoint interni o di debug. I due numeri non si contraddicono: descrivono insiemi diversi.

Il passaggio decisivo: dalla segnalazione alla prova

Un modello può notare nel codice una concatenazione rischiosa o un input non filtrato. Può anche interpretare male il contesto. PageBreak tenta quindi una validazione deterministica: per una possibile XSS verifica se un payload controllato viene davvero eseguito nel browser; per altri tipi di problema usa controlli tecnici adatti al caso. Le ipotesi che non superano questo passaggio restano materiale di approfondimento, non diventano automaticamente ticket per i team di prodotto.

Il principio coincide con il metodo di test descritto nella Web Security Testing Guide di OWASP: individuare i punti d’ingresso, osservare come l’applicazione restituisce l’input e verificare l’effetto nel contesto di esecuzione. Un testo riflesso in una pagina non basta, da solo, a dimostrare una XSS sfruttabile. Servono condizioni, percorso di riproduzione e impatto.

Un flusso pratico per chi gestisce un sito

Non occorre replicare l’infrastruttura di Google per ridurre il rumore degli alert. Si può adottare un processo più piccolo, con responsabilità chiare e test soltanto su sistemi propri o autorizzati:

1. Raccogliere il contesto: URL, parametro, versione del software, ruolo utente e ambiente in cui nasce la segnalazione.
2. Riprodurre in sicurezza: provare il caso in staging con dati di test, senza coinvolgere visitatori o sistemi terzi.
3. Confermare l’effetto: distinguere una stringa sospetta da codice che si esegue davvero o da un accesso non consentito.
4. Assegnare priorità: valutare esposizione pubblica, privilegi necessari, dati raggiungibili e facilità di sfruttamento.
5. Chiudere il ciclo: correggere, ritestare e registrare prova e versione della modifica.

Prima dei test, conviene sapere quali siti, sottodomini, plugin e ambienti sono effettivamente in uso. La nostra guida sulla superficie d’attacco web parte da questo inventario: uno scanner non può dare una copertura affidabile se il perimetro è sconosciuto.

Che cosa PageBreak non dimostra

Un tasso basso di falsi positivi nel flusso di Google non equivale a “nessuna vulnerabilità mancata”. Il report ammette che alcuni problemi complessi potrebbero non avere ancora un validatore adeguato. Inoltre l’agente dispone di accessi e segnali che una realtà esterna normalmente non possiede. La conclusione ragionevole non è delegare ogni decisione di sicurezza a un chatbot, ma combinare strumenti automatici, prove ripetibili e revisione umana.

Il racconto tecnico di Google Bug Hunters mostra esempi dei problemi scoperti da PageBreak; resta una descrizione del produttore, non una valutazione indipendente delle sue prestazioni. Per chi sviluppa, il confronto più utile è tra due abitudini: aprire decine di ticket su ipotesi non provate oppure dedicare tempo a poche evidenze che spiegano esattamente come il difetto si manifesta.

Una lezione utile anche fuori da Google

PageBreak rende visibile un cambio di metodo: l’AI può ampliare l’esplorazione, ma il valore operativo arriva quando una segnalazione diventa verificabile e correggibile. Se oggi ricevi alert generati da scanner o assistenti AI, chiedi una prova riproducibile prima di assegnare priorità massima. E se il caso non si riproduce, non archiviarlo alla cieca: documenta quali condizioni mancavano e quando riprovare.