ISGroup Conseil en Cybersécurité

Sécuriser vos applications Google, Firebase et Cloud développées avec l’IA

Quiconque développe sur la stack Google aujourd’hui peut utiliser des outils très différents les uns des autres : Gemini Code Assist dans l’IDE, Gemini CLI dans le terminal, Jules comme agent asynchrone sur les dépôts, Google Antigravity comme environnement “agent-first”, Firebase et Google Cloud comme backend et infrastructure. L’avantage est évident : le code, les tests, l’UI, les correctifs et les configurations peuvent progresser beaucoup plus rapidement.

Le risque survient lorsque cette vitesse traverse plusieurs surfaces simultanément. Une modification peut partir d’un prompt, passer par le dépôt, exécuter des commandes dans le terminal, être vérifiée dans le navigateur et finir dans Firebase, Cloud Run, Cloud Functions, Cloud Storage ou IAM. Avant la mise en production, la question n’est pas de savoir si les outils Google sont utiles, mais ce qu’ils ont modifié dans le produit : code, API, autorisations, règles Firebase, comptes de service, secrets, stockage, déploiement et données réelles.

Pour une équipe “Google-native”, la sécurité ne se limite pas à la revue de code ou à l’évaluation de la sécurité cloud. Il est nécessaire d’examiner le comportement de l’application, le code généré, les configurations Firebase et Google Cloud, ainsi que le processus par lequel l’agent a produit ou validé les modifications.

[Callforaction-WAPT]

Pourquoi l’écosystème de codage IA de Google doit être traité comme un périmètre unique

Gemini Code Assist, Antigravity et Jules n’ont pas le même modèle opérationnel. Gemini Code Assist travaille dans le contexte du développeur et de l’IDE. Jules peut prendre en charge des tâches asynchrones, cloner le dépôt dans un environnement cloud, installer des dépendances, modifier des fichiers et préparer des changements à réviser. Antigravity, selon les communications de Google sur Gemini 3, oriente les agents vers une expérience où l’éditeur, le terminal et le navigateur sont des surfaces opérationnelles coordonnées.

Cette différence compte. Une suggestion en ligne qui modifie une fonction a un impact limité et visible. Un agent qui modifie des fichiers, exécute des tests, installe des paquets et vérifie l’UI dans le navigateur produit un résultat plus large : code, dépendances, configurations, logs, captures d’écran, tests et hypothèses sur le comportement de l’application. Si le backend est Firebase ou Google Cloud, le passage de “ça fonctionne” à “c’est publiable” nécessite des contrôles spécifiques : il ne suffit pas que l’artefact soit fonctionnel, il faut vérifier ce qui a changé dans les limites d’autorisation, les données, les points de terminaison (endpoints), les règles d’accès et les privilèges cloud.

Gemini Code Assist : mode agent, contexte et zones sensibles

Gemini Code Assist peut aider avec des explications, la génération de code, le refactoring, le mode agent et les activités sur le dépôt. Lorsqu’il travaille sur des zones applicatives sensibles, la revue doit se concentrer sur les points que l’assistant ne peut pas connaître de manière exhaustive : règles métier, isolation des tenants, rôles internes, données réelles, conformité, conventions d’entreprise et décisions architecturales non documentées.

Les risques les plus concrets apparaissent lorsqu’une suggestion touche à l’authentification, aux autorisations, aux middlewares, aux routes, à la validation des entrées, à la gestion des erreurs, à la journalisation (logging), aux dépendances ou aux configurations de déploiement. Une modification peut être cohérente avec le prompt mais erronée par rapport au produit : un contrôle peut être déplacé dans le frontend, une route peut être créée sans authentification côté serveur, un test peut ne confirmer que le chemin nominal.

Avant la fusion (merge), les modifications générées ou corrigées avec Gemini Code Assist doivent être lues comme des diffs de production. Si elles concernent des API, des données ou des rôles, des tests négatifs sont nécessaires : utilisateurs non autorisés, objets d’autres utilisateurs, différents tenants, jetons expirés, requêtes hors séquence, payloads manipulés et accès direct à des routes non exposées dans l’UI.

Antigravity : éditeur, terminal et navigateur dans le même flux de travail

Antigravity déplace l’attention de l’assistance individuelle dans l’IDE vers un flux plus “agentique”. Google le décrit comme une plateforme où les agents peuvent avoir un accès direct à l’éditeur, au terminal et au navigateur. Ce modèle est puissant car il permet de planifier, modifier, exécuter et vérifier de manière plus intégrée, et c’est précisément pour cette raison que le contrôle doit être plus rigoureux.

Lorsqu’un agent travaille entre le terminal et le navigateur, une erreur ne reste pas confinée au fichier modifié : elle peut devenir une commande shell, une installation de paquets, un test d’UI, une modification de configuration, le démarrage d’un service local, une sortie contenant des secrets, des captures d’écran avec des données sensibles ou un déploiement lancé trop tôt. La revue doit inclure ce qui a été exécuté, pas seulement ce qui a été écrit.

L’installation, la migration, le déploiement, la suppression, la CLI cloud, la modification des variables d’environnement et les configurations Firebase ou Google Cloud devraient nécessiter une approbation explicite. Les commandes exécutées par l’agent doivent être tracées lorsque le dépôt contient des données, des clés ou des accès à des services réels. Si le navigateur enregistre des sessions, des captures d’écran ou des flux, il est nécessaire d’éviter que des données personnelles, des jetons, des tableaux de bord administratifs et des informations client inutiles n’y soient intégrés.

Jules : PR autonomes, VM cloud et tests fonctionnels

Jules est conçu pour déléguer des tâches de développement : corrections de bugs, tests, documentation, fonctionnalités et mises à jour. Il travaille en clonant le code dans une machine virtuelle, en installant des dépendances et en modifiant des fichiers. Cela réduit l’impact sur l’environnement local, mais ne prouve pas que le résultat est sécurisé.

Une PR générée par Jules peut être bien organisée, compiler et réussir les tests, tout en contenant une dérive des dépendances (dependency drift), des tests qui confirment le nouveau comportement sans le défier, une logique d’autorisation simplifiée, un contrôle des erreurs trop permissif, des paquets ajoutés pour résoudre un problème ou des configurations d’environnement modifiées pour permettre la compilation.

Avant d’accepter une PR générée de manière asynchrone, l’équipe doit réviser les diffs, le lockfile, les scripts d’installation/build/test, les fichiers de configuration, les nouvelles routes, les middlewares, les tests mis à jour et les données utilisées dans l’environnement. La VM ne devrait pas recevoir de secrets de production ou d’accès à des systèmes réels non nécessaires à la tâche. Si Jules a corrigé ou ajouté des tests, il faut comprendre s’ils couvrent les abus et les régressions de sécurité ou seulement le chemin prévu.

Règles Firebase générées ou modifiées par IA

Firebase est souvent le point où un prototype “Google-native” devient un produit : Authentification, Firestore, Realtime Database, Cloud Storage, Functions, Hosting et intégrations. Le risque le plus courant est de penser qu’un contrôle dans l’UI équivaut à une règle de sécurité.

Firestore, Realtime Database et Cloud Storage doivent avoir des règles qui partent d’un “default deny” (refus par défaut) et n’ouvrent que des cas explicites. Si l’assistant génère des règles pour “faire fonctionner” la lecture et l’écriture, il faut vérifier la propriété, le rôle, le tenant, l’état du document, les revendications personnalisées (custom claims) et la séparation entre les données publiques et privées. Des règles comme l’accès authentifié générique ou des chemins trop larges peuvent être suffisantes pour une démo et dangereuses en production.

La revue doit inclure des tests avec différents utilisateurs, des utilisateurs anonymes, des jetons expirés, des documents d’autres tenants, des fichiers privés, des téléchargements, des suppressions et des opérations hors séquence. Les règles de sécurité Firebase doivent être testées avec des émulateurs et des cas négatifs, pas seulement essayées depuis l’UI : si une règle autorise la lecture ou l’écriture parce que le frontend n’affiche pas le bouton, le contrôle est au mauvais endroit.

Google Cloud IAM et comptes de service

Les outils d’IA peuvent aider à écrire du code qui utilise Google Cloud, mais les comptes de service et IAM restent une surface critique. Le risque typique est d’utiliser des rôles trop larges pour faire fonctionner Cloud Functions, Cloud Run, le stockage, les bases de données, le planificateur (scheduler) ou les intégrations.

Un compte de service ne devrait pas avoir les rôles Propriétaire (Owner), Éditeur (Editor) ou des rôles primitifs par commodité. Chaque charge de travail devrait avoir une identité dédiée, des permissions minimales, éviter les clés statiques lorsque possible et auditer l’usurpation d’identité (impersonation) et les accès. Si l’agent suggère de créer ou de télécharger une clé JSON, l’équipe doit se demander s’il existe une alternative plus sécurisée et si cette clé peut finir dans le dépôt, les logs, les prompts ou les artefacts.

Pour les applications Firebase et Google Cloud générées avec l’IA, l’évaluation de la sécurité cloud et la revue de code doivent se rencontrer : le code montre comment les comptes de service et les API sont utilisés, tandis que la configuration cloud montre ce que ces rôles peuvent réellement faire. Une vulnérabilité applicative devient plus grave si le compte de service associé peut lire le stockage, la base de données ou les secrets au-delà du nécessaire.

Jetons, clés API et secrets dans le frontend

L’une des confusions les plus fréquentes dans les applications Firebase est la différence entre les configurations côté client prévues et les secrets côté serveur. Certaines valeurs Firebase sont conçues pour être utilisées par le client avec des règles de sécurité robustes. D’autres jetons, clés privées, secrets de webhook, clés de compte de service et identifiants de fournisseurs externes doivent rester côté serveur.

Les assistants IA peuvent générer du code qui semble fonctionner mais place des valeurs sensibles dans les bundles frontend, les fichiers .env exposés, les logs, les tests ou les exemples. Avant le déploiement, il faut rechercher les clés dans le dépôt, l’historique, les prompts, les logs de build, les artefacts et le code servi au navigateur. Les clés API publiques doivent être limitées avec des restrictions appropriées ; les secrets privés doivent être gérés dans Secret Manager, lus uniquement par le runtime côté serveur et jamais imprimés. Si une clé a fini dans un contexte non prévu, la supprimer du fichier ne suffit pas : elle doit être renouvelée (rotation).

Cloud Functions, Cloud Run et API exposées

De nombreuses applications créées avec des outils d’IA Google utilisent Cloud Functions, Cloud Run ou des endpoints API pour connecter le frontend, la base de données, le stockage, les paiements, le CRM, la billetterie ou les modèles d’IA. Ce sont des surfaces exposées qui doivent être testées comme telles.

Les problèmes les plus courants sont les endpoints publics sans authentification, un IAM invoker trop permissif, un CORS ouvert, des erreurs détaillées, des callbacks et redirections non listés dans une “allowlist”, l’absence de limitation de débit (rate limit), une validation des entrées insuffisante, des logs contenant des PII (données personnelles) ou des jetons. Un agent peut générer un endpoint pour compléter rapidement une fonctionnalité sans appliquer la même discipline de sécurité que celle présente dans le reste du backend.

Avant la mise en production, chaque endpoint doit être appelé directement en dehors du flux UI. Il faut essayer l’accès anonyme, les utilisateurs avec un rôle faible, différents tenants, des payloads manipulés, des requêtes répétées, des callbacks non prévus, des fichiers malveillants et des conditions d’erreur. Si l’application est accessible en ligne, le WAPT (Web Application Penetration Test) doit vérifier le comportement réel, pas seulement le code.

Dépendances, SDK et scripts d’installation

Gemini Code Assist, Jules ou Antigravity peuvent ajouter des paquets, mettre à jour des SDK, modifier des lockfiles ou changer des scripts de build. Ces modifications semblent opérationnelles, mais elles affectent la chaîne d’approvisionnement (supply chain) et doivent être révisées avec la même attention que le code applicatif.

Chaque modification de package.json, requirements.txt, pyproject.toml, lockfile, script postinstall, build ou test doit être examinée pour comprendre pourquoi le paquet a été introduit, s’il est maintenu, quelle licence il possède, quelles dépendances transitives il apporte, s’il existe des vulnérabilités connues et si le script exécute du code non prévu.

Dans le contexte Google et Firebase, il convient de prêter attention aux SDK obsolètes, aux bibliothèques qui gèrent les jetons et les sessions, aux wrappers non officiels pour les services cloud et aux paquets aux noms quasi identiques. Une PR générée par l’agent peut être acceptée parce qu’elle résout une erreur de build, mais introduire une dépendance que l’équipe n’aurait pas approuvée manuellement.

Données réelles dans les prompts, logs, captures d’écran et VM

Les agents qui travaillent entre l’éditeur, le terminal, le navigateur et la VM peuvent voir plus de contexte qu’un simple chatbot : fichiers, sorties de tests, captures d’écran, erreurs, logs, payloads, tickets, documentation interne et sessions de navigateur. Cela augmente l’utilité, mais aussi le risque de divulgation de données.

Pour le débogage et la validation, il est préférable d’utiliser des données synthétiques ou minimisées. Les captures d’écran de tableaux de bord, les enregistrements de navigateur, les logs de Cloud Functions, les dumps Firestore, les payloads de webhook et les tickets client ne devraient pas entrer dans le contexte de l’agent s’ils ne sont pas strictement nécessaires. Lorsqu’ils y entrent, il faut savoir où ils sont conservés, pour combien de temps et qui peut y accéder.

Le contrôle n’est pas seulement une question de confidentialité. Des données réelles dans les tests peuvent faire passer une modification parce que le jeu de données est favorable, alors qu’elle échoue sur des cas limites. Pour la sécurité, il faut des jeux de données qui incluent différents rôles, des tenants, des enregistrements non autorisés, des fichiers privés, des utilisateurs désactivés et des entrées malveillantes.

Checklist avant la mise en production

Outils et flux de travail

  • Identifiez quels outils ont contribué au code : Gemini Code Assist, Antigravity, Jules, Gemini CLI ou d’autres outils Google.
  • Rassemblez les PR, diffs, branches, commandes terminal, tests exécutés, enregistrements de navigateur, captures d’écran et artefacts.
  • Si un agent a travaillé dans une VM ou de manière asynchrone, vérifiez quelles dépendances il a installées et quels fichiers il a modifiés.

Firebase et données

  • Révisez les règles Firestore, Realtime Database et Cloud Storage avec une approche “default deny”.
  • Testez l’accès avec des utilisateurs anonymes, des utilisateurs authentifiés, différents rôles, différents tenants et des fichiers non autorisés.
  • Vérifiez l’authentification, les revendications personnalisées (custom claims), les invitations, la réinitialisation de mot de passe, les contenus premium, les téléchargements et les suppressions.
  • Si des données réelles sont utilisées, contrôlez les logs, la rétention et les sauvegardes.

Google Cloud et IAM

  • Contrôlez les comptes de service, les rôles IAM, les clés statiques, l’usurpation d’identité, l’invoker Cloud Run/Functions, le stockage, Secret Manager, Cloud Logging et les environnements.
  • Évitez les rôles primitifs par commodité.
  • Chaque charge de travail doit avoir une identité et des permissions cohérentes avec ce qu’elle doit faire.

API, frontend et secrets

  • Vérifiez les routes publiques, CORS, callbacks, redirections, clés API, jetons dans le frontend, secrets côté serveur, gestion des erreurs et limitation de débit.
  • Effectuez une analyse des secrets (secret scanning) sur le dépôt, l’historique, les logs, les prompts et les artefacts.
  • Renouvelez toute clé ayant fini au mauvais endroit.

Dépendances et tests

  • Révisez les lockfiles, SDK, paquets ajoutés, scripts d’installation/build/test et tests générés.
  • Intégrez des tests négatifs sur IDOR/BOLA, l’isolation des tenants, l’abus de rôles, les téléchargements malveillants, la logique métier et les sessions expirées.
  • Si l’application ou les API sont en ligne, exécutez un WAPT sur l’environnement exposé.

Quand une revue interne suffit-elle et quand une vérification indépendante est-elle nécessaire ?

Une revue interne peut suffire si les outils Google AI ont produit des modifications isolées, non exposées, sans données réelles, sans règles Firebase, sans IAM, sans compte de service et sans API publiques. Même dans ce cas, il est utile de savoir quelles parties ont été générées et lesquelles ont été contrôlées par une personne compétente.

Une vérification indépendante est nécessaire lorsque l’application utilise Firebase ou Google Cloud avec des données réelles, lorsque des règles d’accès, des comptes de service, Cloud Functions, Cloud Run, des API, du stockage, des callbacks, des redirections, des dépendances ou des déploiements ont été modifiés. Elle est également nécessaire lorsque Jules ou Antigravity ont produit des PR importantes, exécuté des commandes ou validé le comportement uniquement avec des tests fonctionnels.

Le but n’est pas de ralentir les outils Google. C’est de séparer ce qui peut être accéléré de ce qui doit être vérifié : autorisations, données réelles, surfaces publiques, secrets, comptes de service, règles, API et configurations cloud.

Comment ISGroup vérifie une application Google, Firebase et Cloud créée avec l’IA

Le contrôle change en fonction de ce que Gemini Code Assist, Antigravity ou Jules ont modifié. Si le risque se situe dans le code, les PR, les middlewares, la validation des entrées, l’utilisation des secrets ou les dépendances, la Revue de Code aide à identifier les vulnérabilités et les régressions avant la fusion. Si l’application ou les API sont accessibles en ligne, le Web Application Penetration Testing vérifie le comportement réel de l’extérieur. Si le risque concerne Firebase, Google Cloud, IAM, les comptes de service, le stockage, Cloud Run ou Cloud Functions, le Cloud Security Assessment vérifie les configurations et les privilèges dans le contexte réel.

Si l’outil Google AI a touché… Risque principal Contrôle conseillé
Code applicatif, PR Jules, middleware, validation, gestion des erreurs, dépendances Vulnérabilités ou régressions dans le code Revue de Code
Web app, API, Cloud Functions, Cloud Run ou routes exposées Comportements abusables de l’extérieur Web Application Penetration Testing
Règles Firebase, Cloud Storage, IAM, comptes de service, Secret Manager, config Google Cloud Mauvaise configuration cloud ou privilèges excessifs Cloud Security Assessment
Limite de confiance, multi-tenant, flux de données, intégrations, paiements, LLM intégrés Hypothèses architecturales faibles Secure Architecture Review
Utilisation continue de Gemini, Antigravity ou Jules dans le cycle de publication Contrôles non répétables sur les releases et pipelines Software Assurance Lifecycle

Le choix du contrôle dépend de ce qui a réellement changé : code, comportement exposé, Firebase et Google Cloud, architecture ou processus de développement. Avant la mise en production, il convient de délimiter ce périmètre et de vérifier le risque effectif sur l’application.

Vous avez utilisé Gemini Code Assist, Antigravity ou Jules sur une application qui utilise Firebase ou Google Cloud ? ISGroup peut vous aider à vérifier le code, les API, les autorisations, les règles Firebase, les comptes de service, les secrets, le stockage et les configurations cloud avant que des données réelles et des utilisateurs n’entrent en production.

Éléments de preuve à préparer avant la revue

Avant d’impliquer une équipe externe, il convient de préparer le dépôt, les PR, les branches, les diffs, la liste des outils utilisés, les URL des environnements, la description des rôles, le projet Firebase, le projet Google Cloud, les comptes de service, les règles, Cloud Functions et Cloud Run, les API, les buckets de stockage, les callbacks, les redirections et les dépendances principales.

Sont également utiles les logs et artefacts purgés des données sensibles, la liste des commandes exécutées, les tests générés, les enregistrements de navigateur si disponibles, les décisions déjà prises sur les risques acceptés et les remédiations planifiées. Ces éléments permettent de distinguer les problèmes de code des mauvaises configurations cloud, les vulnérabilités applicatives des lacunes de processus, les risques immédiats des améliorations planifiables.

La question à se poser avant la publication

La décision ne devrait pas être “acceptons-nous ou non la PR de l’agent” dans l’abstrait. Elle devrait être : quelles données expose-t-elle, quelles règles change-t-elle, quels comptes de service utilise-t-elle, quels endpoints publie-t-elle, quels secrets traite-t-elle et quel risque résiduel reste-t-il après la remédiation ?

Gemini Code Assist, Antigravity et Jules peuvent accélérer considérablement le développement sur la stack Google. La sécurité sert à éviter que cette vitesse n’amène en production des règles Firebase trop larges, des comptes de service excessifs, des API abusables, des jetons dans le frontend, du stockage accessible ou des PR non réellement comprises. La question finale est simple : l’application Google, Firebase et Cloud créée ou modifiée avec l’IA a-t-elle été vérifiée comme un produit exposé, ou seulement acceptée parce qu’elle fonctionne dans les tests ? Si la réponse n’est pas claire, l’étape suivante n’est pas de ralentir le développement : c’est de délimiter le risque avant que des données réelles, des utilisateurs, des comptes de service et des surfaces publiques n’entrent en production.

FAQ

  • Gemini Code Assist rend-il le code qu’il génère sécurisé ?
  • Non. Il peut aider à produire et réviser du code, mais l’équipe doit vérifier la logique applicative, les autorisations, les dépendances, les secrets, les règles Firebase et le comportement réel avant la production.
  • Jules travaille dans une VM : cela suffit-il pour faire confiance à la PR ?
  • Non. La VM isole l’exécution de la tâche, mais la PR peut toujours introduire des bugs d’autorisation, une dérive des dépendances, des tests faibles, une gestion des erreurs risquée ou des configurations incohérentes avec le produit.
  • Antigravity est-il plus risqué qu’un IDE traditionnel ?
  • Le risque change car l’agent peut opérer entre l’éditeur, le terminal et le navigateur. Cela augmente la productivité, mais nécessite un contrôle sur les commandes, les diffs, les tests, les données visibles et les configurations touchées.
  • Les règles de sécurité Firebase générées par IA sont-elles fiables ?
  • Elles doivent être vérifiées. Une règle qui fait fonctionner la démo peut être trop ouverte pour la production. Il faut des tests avec différents utilisateurs, des tenants, des rôles, des fichiers privés et des opérations non autorisées.
  • Quand un Cloud Security Assessment est-il nécessaire ?
  • Lorsque le développement assisté par IA a touché Firebase, Google Cloud, IAM, les comptes de service, Cloud Run, Cloud Functions, Cloud Storage, Secret Manager, les callbacks, les redirections ou les configurations de déploiement.

[Callforaction-CSA-Footer]

Sources et références utiles

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *