Sécurité des données — Dévellopement assisté par IA & Réalité opérationnelle

L'agent code l'interface en deux heures. La base de données reste en libre-service.

Les réseaux sociaux s'étourdissent de vidéos vantant le « vibecoding » : monter un SaaS en un week-end sans écrire une ligne de code, simplement en conversant avec un modèle. L'entreprise de cybersécurité UpGuard vient de siffler la fin de la récréation avec un chiffre glacial : 16 326 bases Supabase exposent au moins une table critique directement sur l'Internet public. Pas de zero-day. Pas de piratage sophistiqué. Juste des applications dont personne n'a compris la configuration.

Rapport UpGuard : 16 326 instances Autopsie d'une fuite industrielle

L'ampleur du désastre : ce que les chercheurs d'UpGuard ont extrait

Supabase s'est imposé comme la brique backend par défaut de l'écosystème IA : un moteur PostgreSQL robuste enveloppé d'une couche d'authentification, de stockage et d'une API REST/GraphQL instantanée. C'est l'outil rêvé pour les agents de génération de code comme Cursor, Claude Code ou v0.

Les équipes d'UpGuard ont scanné environ 300 000 domaines présentant l'empreinte technique d'une intégration Supabase. La méthode est déconcertante de simplicité : interroger les routes d'API publiques à la recherche d'une table users ou inspecter les réponses du schéma exposé. Le résultat documenté donne le vertige :

Le tableau de chasse des données compromises
  • • Service de voiturier (États-Unis) : Plus de 100 000 fiches clients accessibles, incluant identités, numéros de téléphone, plaques d'immatriculation et historique complet des déplacements.
  • • Cabinet d'immigration (Canada) : Dossiers de près de 5 000 usagers en situation de vulnérabilité, dont 884 mots de passe stockés en clair dans la base.
  • • Plateforme de créateurs adultes (Inde) : Données d'identité bancaire, comptes de reversement et plus de 100 000 messages privés intimes lisibles sans session.
  • • Fournisseur de passerelle OTP (Philippines) : 2 000 comptes et 100 000 SMS interceptés, révélant des échanges privés sans aucun rapport avec le service d'authentification.
  • • Services consulaires (Afrique) : Registres de 25 000 ressortissants, coordonnées privées et adresses précises de structures d'hébergement d'urgence.

Le fil rouge : le décrochage de compétences

Ce n'est pas le type de service qui pose problème, mais le profil de ses créateurs : celui qui comprend ce que vend l'application n'a aucune idée de la façon dont sa base de données est configurée. Plus de 60 % des nouvelles bases de données Supabase proviendraient aujourd'hui d'environnements assistés par IA. Bien qu'UpGuard précise que leur scan n'établit pas une preuve directe pour chaque site pris isolément, la corrélation industrielle est implacable : l'accélération artificielle du code multiplie mécaniquement les déploiements aveugles.

Non, Supabase n'est pas troué : vous avez laissé la porte grande ouverte

Il est crucial de dissiper l'alibi technique : ce désastre n'est pas une faille de Supabase. PostgreSQL fonctionne exactement comme on lui a ordonné de fonctionner. Le problème réside dans l'incompréhension radicale du modèle d'exposition de PostgREST et de la sécurité par politique de lignes :

1. L'illusion du Row Level Security (RLS)

Dans l'interface graphique de Supabase, créer une table active désormais le Row Level Security par défaut. Mais les agents de code ne cliquent pas dans une interface : ils exécutent des scripts SQL bruts (DDL), appliquent des migrations ou interagissent via l'API. Or, un CREATE TABLE exécuté en SQL dans Postgres crée par défaut une table sans RLS, ouverte aux quatre vents.

2. La clé « anon » n'est pas un secret

La clé anon fournie par Supabase est injectée côté client dans le navigateur. Elle est conçue pour être publique, comme une clé d'API Google Maps. Son rôle n'est pas de verrouiller la base, mais d'identifier le rôle PostgreSQL anon. Si la table n'a pas de RLS activé, ou si l'agent IA a généré une politique paresseuse du type CREATE POLICY ON users FOR SELECT USING (true); pour faire disparaître une erreur 403, n'importe qui armé d'un simple appel curl peut siphonner l'intégralité du contenu.

3. La confusion des clés d'infrastructure

Pire encore : certains projets vibecodés injectent directement la clé service_role (qui outrepasse toutes les politiques de sécurité) dans les variables d'environnement frontend (NEXT_PUBLIC_). C'est l'équivalent numérique de clouer le trousseau de passe-partout sur la boîte aux lettres dans la rue.

La rupture de charge et l'asymétrie du prompt : les attaquants vibent aussi

Le vibecoding est une formidable révolution d'accessibilité pour prototyper. Concevoir un CRM jouet, une maquette cliquable ou un bot interne en quarante-huit heures est une prouesse réelle. Mais un prototype n'est pas un système de production.

La catastrophe commence au moment précis où l'application est mise en contact avec de véritables êtres humains : des cartes d'identité, des mots de passe, des SMS d'authentification bancaire et des plaques minéralogiques.

La complaisance de l'agent face à l'assaillant

L'agent d'IA optimise exclusivement pour une métrique : « faire fonctionner l'affichage à l'écran sans friction ». Il n'a aucun modèle mental de l'attaquant qui, lui aussi, utilise des modèles de langage pour orchestrer ses attaques : « Écris un script pour énumérer les sous-domaines Supabase, tester la présence d'une table users sans token et dumper les colonnes sensibles ».

Les défenseurs célèbrent leur vitesse de développement sur les réseaux. Les attaquants, eux, n'ont pas de réunion produit : ils automatisent le scan de 300 000 cibles en continu. Déployer en production sans comprendre les politiques RLS, le hachage cryptographique et l'isolation des rôles ne relève pas de l'agilité : c'est une négligence contractuelle dont la facture est exigible immédiatement.

Check-list d'urgence avant de « ship »

Avant de publier la moindre URL manipulant des données réelles, l'audit de ces six verrous n'est pas négociable :

  1. [1. AUDIT DU SECURITY ADVISOR]

    Ouvrez l'onglet Security Advisor dans le tableau de bord Supabase. Corrigez immédiatement chaque alerte rouge concernant les tables exposées sans protection. Pas « lors du prochain sprint », tout de suite.

  2. [2. RLS ACTIF ET POLITIQUES RESTRICTIVES]

    Exécutez systématiquement ALTER TABLE nom_de_table ENABLE ROW LEVEL SECURITY; sur l'intégralité de vos schémas publics. Définissez des politiques explicites et testez-les impérativement sous deux cas d'usage distincts : avec un rôle anon (non connecté) et avec un token JWT authenticated.

  3. [3. SANCTUARISATION DU SERVICE_ROLE]

    La clé service_role ne doit jamais figurer dans le code source d'un client (React, Vue, mobile). Elle doit rester confinée à un environnement backend sécurisé (fonctions Edge, serveur Go/Node privé).

  4. [4. PROSCRIPTION DES MOTS DE PASSE EN CLAIR]

    Déléguez l'authentification au module auth.users natif de Supabase. Si vous créez manuellement une colonne password lisible en texte brut dans une table applicative, vous avez déjà failli à l'ingénierie logicielle élémentaire.

  5. [5. TEST DU SCRAPER À BLANC]

    Ouvrez une fenêtre de terminal sans session authentifiée et lancez : curl -H "apikey: CLE_ANON" "https://votre-projet.supabase.co/rest/v1/users?select=*". Si le terminal renvoie la moindre donnée utilisateur, votre système est vulnérable.

  6. [6. AUDIT HUMAIN SYSTÉMATIQUE DES PII]

    Dès qu'un schéma manipule des informations personnelles identifiables (PII), exigez la relecture de la couche de données par un ingénieur backend ou un auditeur de sécurité qualifié. L'approbation d'un chatbot ne constitue pas une garantie légale.

Verdict d'atelier

Le vibecoding est une révolution pour explorer. La production, elle, n'écoute pas la vibe : elle applique strictement vos règles de configuration.

• L'illusion du « full-stack IA » : Générer du HTML et du style Tailwind ne dispense en rien de maîtriser les permissions de son moteur relationnel.

• Le prix de l'ignorance : Laisser une base ouverte ne demande aucun exploit de hacker de cinéma : il suffit d'une URL et d'une requête GET.

• Règle de fer : Ce n'est pas parce qu'une application fonctionne à l'écran qu'elle est prête à accueillir des utilisateurs réels. La sécurité commence au niveau de la donnée, jamais du prompt.