ISGroup Conseil en Cybersécurité

Supabase, Firebase et Auth0 : erreurs de configuration dans les applications créées avec l’IA

Supabase, Firebase, Auth0 et applications créées par IA : erreurs de configuration fréquentes

Supabase, Firebase et Auth0 permettent de construire rapidement ce qu’un MVP exige presque toujours : base de données, connexion, rôles, stockage, API, callbacks, e-mails et intégrations. En les connectant à un générateur d’applications IA ou à un agent de codage, le prototype peut devenir crédible en quelques jours. La partie fragile n’est pas le fournisseur en soi, mais la configuration qui maintient ensemble le frontend généré, le backend géré et les données réelles.

Le risque typique est une application qui fonctionne en démo mais qui ne sépare pas correctement les utilisateurs, les tenants, les rôles, les buckets, les clés et les environnements. Les outils d’IA ont tendance à résoudre le problème immédiat — lire une table, faire passer une connexion, charger un fichier, corriger une erreur CORS, compléter une redirection — sans nécessairement considérer l’ensemble. Avant la mise en ligne (go-live), il est donc nécessaire de vérifier si ces choix respectent le principe du moindre privilège, l’isolation des données et les contrôles côté serveur.

Cet article s’adresse aux fondateurs techniques, aux développeurs et aux chefs de projet qui ont utilisé Lovable, Bolt.new, v0, Replit Agent, Cursor, Copilot, Codex, Claude Code ou d’autres outils d’IA pour connecter une application web à Supabase, Firebase ou Auth0. La question pratique est la suivante : le backend géré est-il configuré pour supporter des utilisateurs réels, des données réelles et des requêtes directes vers les API ?

Le problème n’est pas d’utiliser un BaaS : c’est de l’utiliser sans frontières claires

Les Backend-as-a-Service et les fournisseurs d’identité sont des outils utiles et matures. Supabase propose des bases de données Postgres, Auth, Storage, Edge Functions et des contrôles comme le Row Level Security (RLS). Firebase propose Firestore, Authentication, Cloud Storage, Functions et des règles de sécurité. Auth0 gère les identités, les connexions, les jetons, les callbacks et les intégrations avec des applications et des API.

Le point critique est la responsabilité partagée : le fournisseur protège la plateforme et offre des fonctions robustes, mais il ne peut pas savoir si la table orders doit être lisible uniquement par le propriétaire, si un tenant ne doit pas voir les fichiers d’un autre, si une callback de staging doit être supprimée, si une clé de rôle de service (service role key) s’est retrouvée dans le frontend ou si un rôle administrateur créé pour la démo est encore trop puissant. Lorsque l’application est générée par IA, cette distinction devient encore plus importante, car le code peut sembler cohérent, l’interface utilisateur peut masquer des actions non autorisées et les tests peuvent passer, mais la sécurité réelle dépend des règles, des politiques, des jetons et des appels API directs, et non seulement du parcours visible dans l’interface.

Supabase : le RLS n’est pas un détail optionnel

Dans Supabase, le Row Level Security (RLS) est le contrôle central pour empêcher des utilisateurs différents de lire ou de modifier des lignes non autorisées. Si une application générée par IA crée des tables, des requêtes et des SDK clients sans politiques cohérentes, le risque est qu’un utilisateur authentifié puisse accéder à des données qui ne lui appartiennent pas.

Le cas le plus dangereux est la table exposée sans RLS ou avec des politiques trop permissives. Une politique using (true) peut être acceptable uniquement sur des données publiques destinées à être lues par tous, mais elle devient critique sur les profils, les commandes, les documents, les espaces de travail, les messages, les tickets, les factures ou les enregistrements multi-tenants. Même les opérations insert, update et delete doivent avoir des conditions cohérentes, pas seulement le select.

Pour vérifier Supabase, il ne suffit pas d’ouvrir le tableau de bord et de voir que l’application fonctionne. Il faut créer deux utilisateurs, deux organisations et des données similaires, puis tester la lecture, la modification, la suppression et l’exportation croisées. Il est important de contrôler auth.uid(), tenant_id, l’appartenance, le rôle et la propriété dans chaque politique, en vérifiant également les fonctions RPC et les vues, qui peuvent devenir des raccourcis capables de contourner le modèle d’autorisation attendu.

Supabase : clé anonyme, clé de rôle de service et frontend

La clé anonyme (anon key) est conçue pour être utilisée par le client, mais sa sécurité dépend entièrement des politiques : si le RLS et les politiques de stockage sont corrects, la clé anonyme ne permet que ce que les politiques autorisent. La clé de rôle de service (service role key) est différente — elle possède des privilèges élevés et ne doit jamais se retrouver dans le frontend, dans le bundle, dans les source maps, dans les logs ou dans le dépôt de code.

Les outils d’IA peuvent brouiller cette frontière. Si une requête échoue en raison de permissions insuffisantes, l’assistant peut suggérer une solution qui utilise une clé plus puissante ou déplace un appel au mauvais endroit : le résultat fonctionne, mais il contourne le modèle de sécurité. Cela arrive souvent lorsque l’équipe veut connecter rapidement un frontend React ou Next.js à Supabase. Avant le déploiement, il est donc nécessaire d’inspecter les bundles frontend, les variables publiques, les fichiers .env, les logs de build, les fonctions serverless et les paramètres de la plateforme. Les variables avec des préfixes côté client comme NEXT_PUBLIC_ ne doivent contenir que des valeurs destinées au navigateur, et toute clé de service exposée doit être renouvelée.

Supabase Storage : buckets, politiques et fichiers privés

Beaucoup d’applications générées par IA ajoutent le téléchargement de fichiers pour compléter une démo — avatars, documents, pièces jointes, images, PDF, exports, captures d’écran ou jeux de données. Si le stockage Supabase est configuré avec des buckets publics ou des politiques ouvertes, la connexion de l’application ne protège pas réellement les fichiers.

La vérification doit inclure qui peut charger, lire, télécharger, supprimer et écraser des fichiers. Un utilisateur ne doit pas pouvoir modifier le chemin ou l’identifiant pour télécharger les documents d’un autre utilisateur, et dans une application multi-tenant, chaque chemin ou métadonnée doit être lié au tenant et à l’appartenance, pas seulement à un nom de fichier généré par le client. Il faut également prêter attention aux aperçus et aux URL signées : un fichier peut être privé mais avoir un aperçu accessible, un lien avec une durée excessive ou des métadonnées révélant des informations sensibles. Pour les fichiers non publics, utilisez des buckets privés, des politiques par utilisateur ou par tenant, des URL signées avec une durée limitée et testez le téléchargement avec différents comptes.

Firebase : des règles de sécurité ouvertes sont le point le plus fragile

Firebase permet de créer rapidement des applications avec des données en temps réel, une authentification et du stockage, mais cette vitesse dépend des règles de sécurité (Security Rules). Firestore et Cloud Storage doivent savoir qui peut lire, écrire, mettre à jour et supprimer chaque document ou fichier : si les règles sont ouvertes pour le développement et le restent, une application fonctionnelle peut tout exposer.

Les règles temporaires sont fréquentes dans les projets accélérés : allow read, write: if true, contrôles trop génériques sur request.auth != null, conditions qui vérifient seulement que l’utilisateur est connecté, jokers (wildcards) de chemin trop larges, absence de contrôle sur le propriétaire, le rôle ou le tenant. Une interface utilisateur générée peut afficher uniquement les données correctes, mais les règles décident de ce qui se passe lorsque quelqu’un appelle directement Firestore ou Storage. Avant la mise en ligne, révisez séparément les règles Firestore et Cloud Storage, adoptez une approche “refus par défaut” et n’ouvrez que les chemins nécessaires. Testez les opérations avec différents utilisateurs, différents rôles, des documents d’autres utilisateurs, des jetons manquants, des jetons expirés et des données hors format. Si l’application utilise Cloud Functions comme couche côté serveur, vérifiez que les fonctions ne réintroduisent pas des accès plus larges.

Firebase App Check : utile, mais ne remplace pas l’authentification et les autorisations

Firebase App Check aide à réduire le trafic provenant de clients non autorisés ou contrefaits vers les services Firebase et les backends compatibles, et il est utile lorsque l’application est exposée et que l’on souhaite réduire les abus d’API, de stockage ou de fonctions. Cependant, il ne décide pas si un utilisateur peut lire le document d’un autre.

App Check doit être traité comme un contrôle supplémentaire : l’authentification, les règles de sécurité et les autorisations applicatives restent nécessaires. Si une règle autorise n’importe quel utilisateur connecté à lire une collection, App Check ne corrige pas la logique d’accès mais limite seulement une partie des abus provenant de clients non attendus. Pour les applications générées par IA, évaluez App Check lorsque vous avez un frontend public, des téléchargements, des appels fréquents aux services Firebase, des fonctions serverless ou des API sensibles. Activez l’application là où c’est approprié, surveillez les requêtes non vérifiées et vérifiez que l’application ne dépend pas d’App Check pour protéger des données qui devraient être protégées par les règles.

Auth0 : une connexion réussie ne signifie pas une autorisation correcte

Auth0 résout une pièce importante : authentifier les utilisateurs, gérer les sessions, émettre des jetons et intégrer des fournisseurs d’identité. La connexion ne prouve cependant pas que l’utilisateur peut effectuer une action déterminée dans l’application. Après l’authentification, le backend doit vérifier l’audience, l’émetteur, la signature, l’expiration, la portée (scope), les rôles, les permissions, la propriété et le tenant.

Une erreur courante dans les applications générées par IA est d’utiliser Auth0 comme si le jeton suffisait pour tout autoriser. Si le code vérifie seulement qu’un utilisateur est connecté, les API et les données restent vulnérables à un contrôle d’accès défaillant. Si les rôles ou les revendications (claims) sont interprétés côté frontend sans vérification côté serveur, un utilisateur peut contourner les contrôles en appelant directement les API. Avant le déploiement, il est donc nécessaire de vérifier quelles API acceptent les jetons d’accès, quelle audience est prévue, quelles portées sont demandées, comment les rôles et les permissions sont mappés, et où le jeton est vérifié. Chaque route sensible doit appliquer des contrôles côté serveur, pas seulement un rendu conditionnel dans l’interface.

Auth0 : callbacks, redirections et domaines de prévisualisation

Pendant le développement avec l’IA, l’équipe ajoute souvent des domaines locaux, des URL de prévisualisation, des environnements Vercel, des redirections temporaires et des callbacks de staging. Auth0 exige que les URL de callback autorisées (Allowed Callback URLs) soient configurées, mais si la liste s’allonge sans nettoyage, elle peut devenir trop permissive.

Le risque est d’accepter des redirections ou des callbacks qui ne sont plus nécessaires, d’anciens domaines de prévisualisation, des jokers larges, des URL de déconnexion incohérentes ou des origines web non alignées avec les environnements réels. Dans les flux OAuth/OIDC, les redirections et l’état de la session font partie de la sécurité, pas seulement de l’expérience utilisateur. Avant la mise en ligne, révisez les URL de callback autorisées, les URL de déconnexion autorisées et les origines web autorisées : ne laissez que les domaines réels, les environnements de staging contrôlés et les URL nécessaires, supprimez les prévisualisations temporaires et évitez les jokers larges.

Dev, staging et production : trois environnements, trois périmètres

Les MVP créés avec l’IA partagent souvent le projet, la base de données ou les clés entre le développement et la production. Cela simplifie la démo, mais rend dangereux le passage aux données réelles : un déploiement de prévisualisation peut écrire dans la base de données de production, un test peut supprimer des données réelles, une clé de staging peut lire des fichiers clients, une callback locale peut rester active en production.

Pour Supabase, Firebase et Auth0, séparez les environnements avec décision : projets différents, bases de données différentes, stockages différents, clés différentes, callbacks différentes, utilisateurs de test séparés et données synthétiques en dehors de la production. Les politiques doivent être versionnées et contrôlées par environnement. Cette séparation est aussi un contrôle contre les agents IA : si l’agent travaille sur un environnement de développement avec des clés limitées, une erreur de configuration a un impact moindre ; s’il travaille avec des identifiants de production, chaque commande ou fichier généré peut devenir un incident.

Tester les politiques : UI, API et SDK

Une configuration BaaS ou Auth ne se valide pas en regardant seulement l’interface. Il faut tester directement les API, les SDK et les règles, car l’interface utilisateur peut empêcher une action tandis que Firestore, Supabase ou une API côté serveur peuvent l’accepter quand même.

Préparez des cas négatifs : utilisateur non connecté, utilisateur avec un rôle faible, utilisateur d’un autre tenant, jeton expiré, identifiant manipulé, fichier d’un autre utilisateur, callback non valide, portée manquante, mauvaise audience, téléchargement hors chemin, mise à jour de champ non autorisée. Chaque test doit démontrer que la donnée est refusée au bon endroit. Pour Supabase, testez les requêtes côté client, RPC, Storage et API exposées ; pour Firebase, testez Firestore, Storage et Functions ; pour Auth0, testez les routes côté serveur, les API protégées, les jetons avec une portée insuffisante et les redirections. Les tests automatiques sont utiles, mais pour la mise en ligne, une vérification manuelle orientée vers l’abus est également nécessaire.

Erreurs fréquentes dans les applications Lovable + Supabase

Lovable est un cas récurrent car il permet de construire rapidement des applications full-stack et est souvent connecté à Supabase. Lorsqu’un MVP généré rapidement utilise Supabase comme base de données réelle sans examen des politiques, le risque se concentre sur le RLS, les buckets, les clés et les requêtes générées pour faire fonctionner immédiatement la démo.

Les erreurs typiques incluent des tables créées pour faire fonctionner une fonctionnalité sans RLS correct, des buckets utilisés pour des téléchargements avec des politiques larges, une clé de rôle de service confondue avec une clé anonyme, des fonctions Edge ou des API qui ne vérifient pas le tenant, et des requêtes qui filtrent côté frontend au lieu de le faire dans la base de données ou le backend. Avant de connecter des données réelles, vérifiez le schéma généré, les migrations, les politiques, les buckets, les variables d’environnement et les fonctions côté serveur. Ensuite, testez deux utilisateurs et deux espaces de travail : si l’application est multi-tenant, ne publiez pas tant qu’un utilisateur d’un tenant n’a pas été bloqué dans sa tentative de lire les données d’un autre.

Quand l’IA corrige une erreur en rendant la configuration plus permissive

Beaucoup de mauvaises configurations naissent d’une correction apparemment raisonnable. La requête ne renvoie pas de données, le téléchargement échoue, la connexion renvoie vers une mauvaise page, un appel API reçoit une erreur 403, une fonction serverless ne lit pas une table. L’assistant propose une modification qui débloque le flux — élargir une politique, ajouter un domaine, rendre public un bucket, utiliser une clé plus puissante, déplacer un appel dans le client ou simplifier une règle Firebase — et le correctif résout le symptôme, mais pas nécessairement le modèle de sécurité.

Si une politique Supabase est élargie pour faire passer un écran, il faut vérifier quels autres utilisateurs peuvent lire cette table. Si une règle Firebase passe d’un contrôle sur le propriétaire à un contrôle sur l’utilisateur connecté, il faut tester les accès croisés. Si une callback Auth0 est ajoutée pour une prévisualisation, elle doit être supprimée lorsqu’elle n’est plus nécessaire. Si une clé de rôle de service résout une erreur, la bonne question est de savoir pourquoi la politique ne permettait pas l’action correcte. Chaque modification suggérée par l’IA sur les politiques, les règles, les callbacks, les portées, les buckets, le CORS, les clés de service et les variables publiques doit être traitée comme une modification sensible : le diff peut être petit, mais changer un allow read ou une callback peut exposer plus de données qu’un refactoring étendu.

Ce qu’il faut corriger avant la mise en ligne

Certaines découvertes sur Supabase, Firebase et Auth0 doivent bloquer la sortie. Le RLS absent sur les tables avec des données privées, les règles de sécurité ouvertes, la clé de rôle de service dans le frontend, les buckets publics non prévus, les callbacks trop permissives, les jetons non vérifiés côté serveur et les environnements de staging connectés à des données de production ne sont pas de la dette technique ordinaire : ce sont des conditions qui peuvent exposer des données dès que l’application reçoit du trafic réel.

La remédiation doit être vérifiable. Activez ou réécrivez le RLS, puis testez différents utilisateurs et tenants. Corrigez les règles Firebase, puis testez la lecture et l’écriture directes. Restreignez les callbacks Auth0, puis vérifiez la connexion, la déconnexion et les redirections uniquement dans les environnements prévus. Déplacez les clés privées hors du frontend, puis vérifiez les bundles et les logs. Si un bucket passe de public à privé, vérifiez également les aperçus, les URL signées et les anciens liens partagés.

D’autres améliorations peuvent être planifiées après la mise en ligne, uniquement avec un risque résiduel clair : mieux documenter les politiques, ajouter des tests automatiques sur les règles, renforcer les alertes, séparer davantage les rôles internes ou améliorer le nommage des variables. Le contrôle minimal sur les données réelles doit cependant être bouclé avant que les utilisateurs et les clients n’entrent dans le système.

Quand une vérification indépendante est nécessaire

Une revue interne peut suffire si l’application utilise des données synthétiques, n’a pas d’utilisateurs externes, n’expose pas de téléchargements, n’a pas de rôles complexes et que l’équipe connaît bien Supabase, Firebase ou Auth0. Dans ce cas, le travail consiste à vérifier le RLS, les règles, les callbacks et les clés avant qu’ils ne passent en production.

Une vérification indépendante est nécessaire lorsque l’application traite des données réelles, utilise le multi-tenant, expose des API, gère des fichiers, connecte des paiements ou des CRM, utilise des rôles administratifs, ou lorsque la configuration a été générée en partie par une IA et que personne n’a testé les politiques contre les abus. Il en va de même si l’équipe ne sait pas distinguer clairement ce qui est contrôlé par le fournisseur et ce qui reste de la responsabilité de l’application.

Comment ISGroup peut vérifier les applications IA avec Supabase, Firebase et Auth0

ISGroup peut vérifier le comportement réel de l’application et les configurations qui connectent le frontend, le BaaS, le fournisseur d’identité, les API et le cloud. L’objectif est de comprendre si les règles protègent réellement les données lorsque l’utilisateur ne suit pas le flux prévu par l’interface utilisateur.

Si l’application IA utilise… Risque principal Contrôle conseillé
Application web, API, flux d’authentification, téléchargements ou routes publiques Abus de l’extérieur, BOLA, IDOR, contournement d’authentification Web Application Penetration Testing
Politiques Supabase, règles Firebase, middleware, requêtes ou gestion des jetons dans le code Logique d’autorisation faible ou régressions Code Review
Projets BaaS/cloud, buckets, stockage, IAM, clés, environnements et comptes de service Mauvaise configuration ou privilèges excessifs Cloud Security Assessment
Services, points de terminaison et composants exposés avec des versions ou configurations connues Vulnérabilités connues et surfaces techniques exposées Vulnerability Assessment
Utilisation continue de générateurs d’IA et d’agents de codage sur les versions successives Contrôles non répétables sur les politiques, l’authentification et les déploiements Software Assurance Lifecycle

Le choix du contrôle dépend de l’endroit où réside le risque : comportement exposé, code, politiques, cloud, stockage ou processus de publication. Pour les applications déjà en ligne, il est conseillé de tester également le comportement réel, et pas seulement de lire les configurations.

Vous avez connecté une application générée par IA à Supabase, Firebase ou Auth0 et vous devez la mettre en ligne ? ISGroup peut vérifier le RLS, les règles de sécurité, les callbacks, les jetons, le stockage, les API, les rôles et les configurations avant la mise en ligne.

Éléments à préparer

Préparez les URL des environnements, les dépôts de code, le projet Supabase/Firebase/Auth0, le schéma de base de données, les politiques RLS, les règles Firebase, les buckets, les callbacks configurées, les domaines de prévisualisation, les variables d’environnement, les fonctions côté serveur, les rôles utilisateur, les tenants, les API et les parties générées par IA.

Des comptes de test sont également nécessaires : utilisateur anonyme, utilisateur standard, utilisateur administrateur et, le cas échéant, deux tenants ou deux espaces de travail. Sans comptes et données de test réalistes, il devient difficile de vérifier les BOLA, les politiques de stockage et les callbacks. Si vous avez déjà reçu des alertes sur des clés exposées, des règles permissives, des buckets publics ou des callbacks non prévues, incluez-les dans la revue : souvent, la découverte visible n’est que le symptôme d’un modèle d’autorisation à corriger.

Checklist avant la mise en ligne

  • RLS actif sur chaque table Supabase contenant des données non publiques.
  • Politiques Supabase spécifiques pour select, insert, update et delete.
  • Aucune clé de rôle de service dans le frontend, dans les logs ou dans le dépôt de code.
  • Supabase Storage avec des buckets privés et des politiques par utilisateur ou par tenant.
  • Règles de sécurité Firestore et Cloud Storage sans ouvertures temporaires.
  • Firebase App Check évalué ou activé là où il réduit les abus.
  • Callbacks Auth0, URL de déconnexion et origines web autorisées sans jokers larges.
  • Audience, portées, rôles et permissions vérifiés côté serveur.
  • Dev, staging et production séparés pour les projets, les clés, les données et les callbacks.
  • Tests manuels avec différents utilisateurs, rôles et tenants sur les API, SDK, téléchargements et exports.

Questions fréquentes

  • Supabase et Firebase sont-ils sécurisés par défaut ?
  • Ce sont des plateformes robustes, mais la sécurité de votre application dépend du RLS, des règles de sécurité, des politiques de stockage, des rôles, des requêtes, des clés et des callbacks configurés dans le projet.
  • La clé anonyme Supabase peut-elle rester dans le frontend ?
  • Oui, si elle est utilisée comme prévu et si le RLS et les politiques limitent correctement l’accès. La clé de rôle de service ne doit en revanche jamais se trouver dans le frontend.
  • Firebase App Check remplace-t-il l’authentification et l’autorisation ?
  • Non. App Check aide à vérifier que les requêtes arrivent de clients attendus, mais il ne décide pas quelles données un utilisateur peut lire ou modifier.
  • Auth0 suffit-il pour protéger les API ?
  • Non. Auth0 authentifie et délivre des jetons, mais les API doivent vérifier le jeton, l’audience, la portée, les rôles, la propriété et le tenant côté serveur.
  • Quand un Web Application Penetration Testing est-il nécessaire ?
  • Lorsque l’application web, les API, la connexion, les téléchargements, les callbacks ou les routes sont exposés en ligne. Le WAPT vérifie le comportement réel de l’extérieur, y compris l’abus de rôles et l’accès direct aux points de terminaison.
  • Quelles erreurs bloquent la mise en ligne ?
  • RLS absent sur des données privées, règles de sécurité ouvertes, clé de rôle de service dans le frontend, buckets publics non prévus, callbacks trop permissives, isolation des tenants non testée, API qui vérifient seulement la connexion et environnements de production partagés avec le staging.

[Callforaction-WAPT-Footer]

Sources et références utiles

In

, , , ,

Leave a Reply

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