Et si l’application que vous venez de lancer en un week-end, fièrement présentée comme un produit « vibe coded », laissait déjà fuiter les noms, adresses, numéros de téléphone et parfois les mots de passe de vos utilisateurs ? C’est précisément le scénario que décrit une enquête de sécurité relayée par TechCrunch : des milliers de bases hébergées chez Supabase seraient accessibles depuis le web public. Pour les fondateurs, marketeurs et équipes produit qui misent sur la vitesse de l’IA, ce n’est plus un détail technique. C’est un risque business, réputationnel et juridique de premier plan.

Ce Que Révèle L’Enquête Sur Les Bases Ouvertes

Le cabinet UpGuard a cherché à mesurer l’ampleur des expositions sur la plateforme. Résultat : environ 16 000 bases présenteraient un degré d’exposition de données personnelles. Pas un bug isolé. Un phénomène de masse, alimenté par la popularité de Supabase auprès des développeurs qui construisent très vite des applications web et mobiles.

Supabase a connu une trajectoire spectaculaire et a atteint une valorisation de l’ordre de 10 milliards de dollars. Cette croissance s’explique en grande partie par l’essor des apps conçues avec des assistants de code. Le backend est prêt en quelques minutes : authentification, stockage, temps réel, API. Le problème n’est pas que la plateforme soit « ouverte par nature ». Le problème, c’est que beaucoup de projets restent configurés comme un bac à sable, alors qu’ils reçoivent déjà de vraies données clients.

Les projets sont sécurisés par défaut. Nous fournissons des réglages sûrs et des outils, et les clients contrôlent la configuration de leurs propres projets.

– Bil Harmer, CISO de Supabase, cité via TechCrunch

Cette phrase résume le modèle classique du cloud : shared responsibility. L’hébergeur durcit la plateforme. L’éditeur de l’application décide qui peut lire quoi. Quand cette seconde partie est négligée, les données se retrouvent indexables, interrogeables, parfois même sans authentification.

Le Vibe Coding Change La Surface D’Attaque

Le vibe coding désigne une manière de construire un produit en dialoguant avec un modèle, en collant des extraits, en déployant dès que « ça marche ». C’est puissant. C’est aussi un accélérateur de dettes de sécurité. L’IA génère souvent un schéma de tables, des politiques d’accès trop permissives, une clé publiée dans le frontend, une désactivation temporaire de contrôles « le temps de tester »… qui reste en production.

Historiquement, les fuites venaient de seaux de stockage mal ouverts, de bases MongoDB sans mot de passe, d’instances Elasticsearch oubliées. Le motif est le même : un service cloud utile, une configuration par défaut mal comprise, un projet qui passe du prototype à la collecte réelle sans revue. La nouveauté, c’est le volume. Des milliers de créateurs non spécialistes de la sécurité publient des apps en quelques heures.

Pour une audience marketing et startup, l’enjeu n’est pas seulement technique. Une landing page qui convertit, un CRM maison, un espace membre, un outil interne de leads : tout cela finit dans une base. Si cette base est publique, votre avantage compétitif et la confiance de vos clients s’évaporent en même temps.

Quelles Données Ont Été Trouvées En Clair

Selon les chercheurs, on retrouve des noms, des adresses, des téléphones, des mots de passe et, plus rarement, des jetons d’authentification. Moins de secrets « premium », mais assez de matière pour du phishing, de l’usurpation d’identité ou du démarchage agressif.

Les exemples cités par TechCrunch donnent le ton. Une base liée à des conversations privées sur un site adulte indien. Des milliers de plaques d’immatriculation d’un service de voiturier aux États-Unis. Les coordonnées de personnes ayant utilisé un service d’immigration et de relocalisation. Une base associée à un consulat d’un gouvernement africain en France. Une autre utilisée pour intercepter des SMS dans une ferme de SIM virtuelles, typiquement pour récupérer des codes OTP et automatiser des fraudes.

La majorité des jeux de données observés semble située aux États-Unis, mais le phénomène est mondial. Des travaux antérieurs avaient déjà pointé des bases liées à des startups Y Combinator et à des applications relativement connues. Autrement dit : ce n’est pas réservé aux side projects étudiants.

• Identifiants civils et coordonnées de contact
• Secrets d’auth parfois stockés sans protection adaptée
• Données métier sensibles (plaques, conversations, dossiers admin)
• Infrastructures potentiellement utilisées à des fins de fraude

Pourquoi Les Startups Tombent Dans Le Piège

Trois forces se cumulent. D’abord la pression de time-to-market. Ensuite l’illusion que « le backend managé s’occupe de la sécu ». Enfin le fait que les politiques Row Level Security (RLS) de Postgres, au cœur de Supabase, demandent une intention claire. Si RLS n’est pas activé, ou si les règles autorisent trop large, l’API publique devient une porte ouverte.

Beaucoup d’outils d’IA proposent un client avec une clé dite « anon ». Cette clé est conçue pour le navigateur, à condition que les règles d’accès soient strictes. Sans ces règles, la clé anon n’est plus un identifiant limité : c’est un sésame. Les tutoriels accélérés insistent sur le « hello world », rarement sur le modèle de menaces.

Ajoutez les webhooks mal protégés, les buckets de stockage publics, les fonctions Edge qui loggent trop, les dumps de développement poussés en prod, et vous obtenez une surface d’attaque que personne n’a cartographiée. L’équipe marketing continue d’acquérir. L’équipe produit itère. Personne n’a le rôle « owner sécurité des données ».

Ce Que Répond La Plateforme

Supabase affirme n’avoir pas eu communication préalable de l’étude complète, tout en soulignant que la sécurité est un chantier permanent. Le CISO insiste sur les défauts sûrs, les outils fournis, et la notification des clients lorsqu’un problème est identifié. La formule est cohérente avec le marché BaaS : on ne peut pas empêcher un client de publier une table ouverte s’il le décide, volontairement ou non.

Pour autant, le débat public porte aussi sur l’expérience développeur. Plus une plateforme rend le déploiement trivial, plus elle a intérêt à rendre la mauvaise configuration difficile. Warnings bloquants, scans automatiques, politiques RLS obligatoires avant d’exposer une table, détection d’accès anonymes massifs : autant de leviers déjà explorés par d’autres acteurs cloud.

Greg Pollock, chercheur chez UpGuard, insiste sur la valeur de cette cartographie : faire prendre conscience. La sensibilisation n’est pas un slogan. C’est souvent le seul filet quand les équipes n’ont pas de RSSI.

Une Histoire Ancienne, Un Volume Nouveau

Les fuites par mauvaise configuration ne datent pas de l’IA générative. On a déjà vu des e-mails militaires, des dossiers de visas, des fichiers classifiés, des scans de permis de conduire, des données d’enfants. Le fil conducteur est toujours l’exposition accidentelle d’un service pensé comme interne.

Ce que change 2025-2026, c’est le nombre de créateurs. Un marketeur peut publier un SaaS de génération de leads. Un community manager peut lancer un espace membres. Un fondateur solo peut coller un backend et encaisser des paiements. La compétence « modèle de données + droits d’accès » n’a pas suivi la même courbe que la compétence « prompt engineering ».

Résultat : Supabase devient un point de concentration visible, simplement parce qu’il est devenu le backend par défaut de beaucoup de prototypes qui ont dépassé le stade prototype. D’autres hébergeurs connaissent les mêmes classes d’incidents. Le nom change. Le mécanisme reste.

Impacts Business, Marque Et Conformité

Pour une startup, une base ouverte n’est pas qu’un sujet IT. C’est une crise de confiance. Les utilisateurs pardonnent un bug d’interface. Ils pardonnent rarement la circulation de leurs conversations, de leurs documents d’immigration ou de leurs identifiants.

Côté acquisition, le coût d’un incident dépasse le communiqué. Support saturé, churn, mauvaises reviews, questions des investisseurs, clauses contractuelles avec des clients B2B, éventuellement notification aux autorités. En Europe, le cadre RGPD rend l’exposition non maîtrisée particulièrement coûteuse : finalité, minimisation, sécurité appropriée, notification.

Côté croissance, le paradoxe est cruel. L’IA vous aide à scaler l’offre. Une fuite scale aussi le préjudice. Dix utilisateurs exposés, c’est gérable. Dix mille leads d’une campagne paid, c’est une base concurrente offerte à tout internet.

Le Cas Des Apps Marketing Et Des Outils Internes

Beaucoup d’expositions ne concernent pas un réseau social grand public. Elles concernent des outils « assez petits pour sembler inoffensifs » : formulaires d’événement, bases d’influenceurs, CRM no-code, outils de scoring, espaces de formation, bots de qualification. Ces systèmes concentrent e-mails professionnels, notes commerciales, historiques d’achat.

Un marketeur qui connecte un tableur, un formulaire et une base Supabase pour « aller plus vite que le SI » crée parfois un shadow IT. Personne n’a revu les droits. Personne n’a chiffré les champs sensibles. Personne n’a limité les origines CORS. Le dashboard interne est ensuite partagé par lien.

La leçon est simple : tout actif qui contient une liste de personnes est un actif à protéger comme un fichier client, pas comme un prototype.

Checklist Pratique Avant De Mettre En Ligne

Voici une grille actionnable, volontairement terre à terre, pour les équipes qui déploient vite.

• Activer RLS sur chaque table métier et refuser l’accès par défaut
• Tester les requêtes avec la clé anon comme le ferait un attaquant
• Ne jamais stocker de mots de passe en clair ; préférer un fournisseur d’auth éprouvé
• Séparer projets staging et production, avec des secrets différents
• Restreindre les buckets de fichiers et signer les URL temporaires
• Limiter les colonnes exposées à l’API ; masquer les champs internes
• Journaliser les lectures anormales et alerter sur les scans
• Prévoir une procédure de notification si une exposition est confirmée

Cette liste n’a rien d’exhaustif. Elle suffit pourtant à éliminer une grande partie des cas « base lisible depuis un navigateur anonyme ».

Ce Que Les Équipes Produit Devraient Exiger De L’IA

Si vous générez du code, imposez un contrat au modèle. Demandez explicitement des politiques RLS restrictives, des exemples de tests d’autorisation, l’absence de secrets dans le dépôt, un schéma de rôles. Relisez ensuite comme si le code venait d’un stagiaire pressé : parce que c’est souvent le niveau de prudence d’un générateur laissé sans spec sécurité.

Les meilleurs flux de travail ajoutent une étape « threat model » de quinze minutes : qui est l’utilisateur, que peut-il lire, que se passe-t-il s’il change son identifiant dans une requête, que voit un tiers qui récupère la clé publique. Quinze minutes. Contre des mois de gestion de crise.

Les agences et studios qui livrent des apps « IA inside » devraient aussi contractualiser un audit de configuration cloud. Ce n’est plus un luxe. C’est un élément de qualité livrable, au même titre que le design system.

Responsabilité Partagée, Mais Risque Asymétrique

Sur le papier, la responsabilité est partagée. Dans la vraie vie, c’est la marque de l’application qui trinque. Les utilisateurs ne retiennent pas le nom de l’hébergeur. Ils retiennent que « l’app X a fuité ». Les journalistes non plus. L’article de TechCrunch le montre : on parle de clients de la plateforme, de cas concrets, de typologies de données.

Cette asymétrie doit gouverner vos priorités. Même si le prestataire notifie, même s’il améliore les defaults, c’est votre registre de traitements, votre DPO, votre relation client. Traitez la configuration comme une fonctionnalité produit, pas comme un réglage d’infra.

Signaux Faibles À Surveiller Dès Cette Semaine

Vous n’avez pas besoin d’attendre un rapport externe. Quelques signaux suffisent : tables accessibles sans session, endpoints qui renvoient trop de lignes, absence de politiques, clés commitées, backups téléchargeables, dashboards publics, absence de rotation des secrets, pas de revue des invitations d’équipe.

Faites un inventaire froid. Listez chaque projet Supabase, son owner, son environnement, le type de données, la date du dernier audit. Si personne ne peut répondre en une heure, vous avez déjà un trou opérationnel.

Ensuite, priorisez par criticité : authentification, paiements, documents d’identité, messages privés, données d’enfants, dossiers administratifs. Tout le reste peut attendre vingt-quatre heures. Pas ces catégories.

Au-Delà De Supabase : Une Leçon Pour Tout L’Écosystème

On pourrait remplacer le nom de la plateforme par n’importe quel backend populaire. Firebase, buckets S3, instances Postgres nues, airtable mal partagé, notions publiques. Le marché de l’IA a seulement augmenté le débit de création d’applications qui collectent sans architecture.

Investisseurs et accélérateurs devraient intégrer une question simple dans les due diligences : « montrez-moi vos politiques d’accès et votre dernier test d’exposition ». Pas un pentest à six chiffres. Un contrôle de configuration. Les YC et autres programmes l’ont déjà appris à leurs dépens lorsque des bases de portfolio apparaissaient dans des scans.

Les outils d’IA, eux, gagneraient à refuser certains patterns : « rends cette table publique pour debugger ». Le debug n’a pas à vivre en production. Un bon copilot devrait proposer un compte de service limité, des fixtures, un environnement isolé.

Comment Parler De Sécurité Sans Freiner La Croissance

Le discours « la sécu ralentit » est souvent un aveu d’absence de process. Des garde-fous bien placés accélèrent : moins d’incendies, moins de refontes, plus de deals enterprise. Un prospect B2B demandera tôt ou tard SOC2, pentest, politique de mots de passe, journalisation. Si votre base était publique six mois plus tôt, la conversation devient délicate.

Intégrez la sécurité dans le rituel produit. Definition of done : « aucune table métier lisible anonymement ». Revue de sprint : « quels champs nouveaux sont personnels ». Campagne d’acquisition : « minimisons les données collectées ». Le marketing data-driven n’a pas besoin de tout stocker pour performer.

La minimisation est d’ailleurs la mesure la plus rentable. Ce qui n’est pas collecté ne fuit pas. Un champ « numéro de permis » dans un MVP de voiturier peut sembler utile. Il devient un cauchemar s’il est public. Demandez-vous si un identifiant interne suffit.

Récit D’Une Exposition Type, Sans Nommer De Victime

Imaginez une app de mise en relation lancée un vendredi. Le générateur crée une table profiles, une table messages, une politique « enable read for all ». Lundi, les premiers utilisateurs arrivent. Mercredi, une campagne TikTok convertit. Vendredi, un scanner internet archive le contenu. Le fondateur découvre le problème quand un journaliste ou un chercheur écrit. Entre-temps, des conversations privées ont circulé.

Ce récit n’est pas de la fiction gratuite. Il condense le rythme réel des incidents modernes : la fenêtre entre « ça marche » et « c’est exposé » s’est réduite à quelques jours. Les robots de scan ne dorment pas. Ils aiment les endpoints prévisibles des BaaS.

Ce Qu’il Faut Retenir Pour Décider

Supabase n’est pas « le problème ». Le problème est l’écart entre la facilité de collecter et la rigueur d’autoriser. L’étude UpGuard met un chiffre sur cet écart : des milliers de projets. Les exemples montrent que le contenu n’est pas anodin. La réponse officielle rappelle que les defaults existent, mais que la configuration reste du ressort du client.

Si vous construisez avec l’IA, ajoutez un rituel de durcissement. Si vous financez ces produits, exigez-le. Si vous y stockez des leads ou des communautés, auditez cette semaine. La vitesse reste un avantage. Elle n’excuse plus l’exposition.

Les prochaines vagues d’apps seront encore plus nombreuses. Les prochaines vagues de scans aussi. Entre les deux, il n’y a qu’une discipline : traiter chaque base comme si elle allait être lue par un inconnu. Parce que, trop souvent, c’est déjà le cas.