L'agent de sécurité IA de Google, PageBreak, a identifié plus de 500 failles de type cross-site scripting (XSS) vérifiées dans les applications web internes de l'entreprise. Le XSS est une classe de bugs d'injection dans laquelle un script fourni par un attaquant s'exécute dans le navigateur d'un autre utilisateur, un risque web de longue date, car le code exécuté sur une page de confiance peut agir avec les privilèges de cette page. Le système teste chaque faiblesse suspectée contre des services en fonctionnement avant qu'un rapport n'arrive à une équipe produit — une étape de validation qui sépare les exploits utilisables des descriptions d'attaques crédibles mais erronées produites par les modèles d'IA. L'approche vise à garantir que chaque rapport confirmé correspond à un exploit fonctionnel plutôt qu'à une simple affirmation plausible.

Google a lancé PageBreak à titre pilote en novembre 2025 et en a fait un projet formel en janvier 2026. L'équipe Product Security de l'entreprise a déclaré que le système avait trouvé des failles XSS sur des domaines sensibles de l'entreprise. Google n'a pas nommé les applications concernées ni divulgué de répartition par gravité ; le chiffre rapporté couvre l'ensemble de son parc d'applications web.

Des validateurs dédiés maintiennent les faux positifs quasiment à zéro

Plutôt que de transmettre chaque alerte directement aux ingénieurs, PageBreak envoie chaque problème candidat à un validateur dédié. Pour une vulnérabilité XSS, le validateur injecte du JavaScript dans la page concernée et observe si le code s'exécute. Google a indiqué que ce processus maintient les faux positifs quasiment à zéro et empêche les affirmations non testées d'arriver aux équipes produit pour examen.

Le système valide davantage que les scripts de navigateur. Des vérifications supplémentaires déterminent si les entrées injectées modifient des requêtes de base de données, exposent des fichiers via une traversée de chemin ou déclenchent une exécution de code, tandis qu'un validateur distinct examine les requêtes pouvant atteindre des services internes. Ces contrôles permettent à PageBreak d'évaluer plusieurs classes d'attaques tout en gardant les rapports concentrés sur les chemins fonctionnels. Chaque candidat exige une preuve indépendante avant que les ingénieurs ne le traitent comme une vulnérabilité.

La plupart des analyses s'exécutent sur Gemini 3.1 Pro ou Gemini 3.5 Flash, mais les vérifications d'exploit sont effectuées par des outils distincts ; les validateurs ne proviennent pas de l'agent IA lui-même. Google répète les tentatives car les modèles peuvent abandonner piste prometteuse ou poursuivre un chemin d'attaque qui échoue dans les conditions réelles de l'application.

Les résultats non vérifiés ne quittent pas le flux de travail de sécurité interne en tant que bugs confirmés. Les équipes peuvent plutôt les utiliser pour affiner les analyses futures ou créer des validateurs supplémentaires. Cette distinction compte, car les modèles de langage peuvent produire des récits de sécurité détaillés qui semblent convaincants mais peuvent ne pas se reproduire lorsqu'ils sont testés contre une application réelle — et, à grande échelle, cet écart détermine si les conclusions générées par l'IA font gagner du temps d'ingénierie ou en consomment lors du triage.

Deux failles détectées dans les applications à frameworks à haute assurance

Au 4 septembre, PageBreak avait identifié deux vulnérabilités XSS parmi des centaines d'applications construites sur les frameworks web à haute assurance de Google. Les deux cas impliquaient des applications internes ou des points de terminaison de débogage auxquels manquaient certaines protections. Ce résultat montre comment ces protections de framework se comportent lors de scans automatisés répétés. Le décompte des frameworks est distinct du total, et n'inclut pas, les plus de 500 conclusions sur l'ensemble plus large du parc applicatif de Google.

PageBreak peut inspecter les chemins de code entre les services via le dépôt de l'entreprise. Les données de sécurité issues du trafic web en direct peuvent relier une page demandée au code source correspondant, et des scanners existants fournissent un accès authentifié aux sites internes.

Cet environnement distingue PageBreak d'un scan public de modèle. Les chercheurs externes ne peuvent généralement pas inspecter le code de Google, ses données de trafic ou ses systèmes de test protégés. PageBreak reflète donc un flux de travail de sécurité interne avec un accès opérationnel approfondi, et le nombre de conclusions ne démontre pas qu'une autre organisation pourrait obtenir les mêmes résultats en exécutant seul Gemini.

Flux de correction : intégration de CodeMender prévue

Google prévoit de connecter PageBreak plus étroitement à CodeMender, un agent conçu pour générer des correctifs de sécurité. Les équipes produit pourraient alors examiner un correctif proposé aux côtés d'une vulnérabilité confirmée — un dispositif qui bouclerait le cycle de la découverte à la correction. L'entreprise a indiqué que cette combinaison pourrait réduire la charge de travail créée par un grand volume de conclusions vérifiées, sans toutefois communiquer de calendrier pour l'intégration.

Des problèmes de vérification comparables touchent les logiciels crypto, où les outils d'IA peuvent générer un grand nombre de rapports de sécurité plausibles. L'Ethereum Foundation a eu recours à des réviseurs distincts pour reproduire les conclusions produites par des agents d'IA, et un scan de la Bitcoin Red Team a révélé que seuls 24,7 % des problèmes signalés à l'époque étaient accompagnés de preuves reproductibles.

Google n'a pas dit si PageBreak sera mis à la disposition de projets externes.

Source : Blockonomi, d'après l'annonce officielle de PageBreak par Google.