Les 5 failles de sécurité que je retrouve dans presque toutes les apps no-code Supabase

Les 5 failles de sécurité que je retrouve dans presque toutes les apps no-code Supabase

En février 2026, Moltbook l'une des apps IA les plus en vue du moment a laissé fuiter environ 1,5 million d'identifiants et 35 000 emails. La cause n'était pas un piratage sophistiqué : c'était un seul réglage de sécurité manquant sur Supabase.

Ce n'est pas un cas isolé. Une étude de mars 2026 a analysé 1 645 applications Lovable publiques : 10,3 % d'entre elles n'avaient pas configuré correctement le Row Level Security. En clair, n'importe quel utilisateur pouvait lire les données des autres. D'autres scans, portant sur plus de 20 000 apps indépendantes, ont trouvé qu'environ une sur neuf exposait ses clés de base de données directement dans le navigateur.

Si vous avez construit votre application avec Lovable, Bolt, v0 ou Replit, ceci vous concerne. Non pas parce que ces outils sont mauvais ils sont remarquables pour passer de l'idée au produit en quelques jours mais parce qu'ils génèrent une app qui fonctionne, pas nécessairement une app qui protège. La sécurité est la partie que la vitesse laisse derrière.

Voici les cinq failles que je retrouve le plus souvent, et comment vérifier si votre app en souffre.

1. Le Row Level Security (RLS) désactivé

Dans Supabase, votre base de données est accessible via une clé publique présente, par conception, dans le code de chaque page de votre site. Ce qui empêche un visiteur de tout lire, c'est le Row Level Security : les règles qui disent « cet utilisateur ne voit que ses propres lignes ».

Quand le RLS est désactivé sur une table, cette clé publique donne un accès complet en lecture et parfois en écriture à toute la table. Commandes, profils, messages, paiements : tout devient consultable par quiconque sait regarder.

Comment vérifier : dans le tableau de bord Supabase, chaque table affiche son statut RLS. Toute table contenant des données utilisateur doit l'avoir activé, sans exception.

2. La clé service_role exposée dans le frontend

Supabase fournit deux clés. La clé anon est faite pour être publique sa présence dans le navigateur est normale. La clé service_role, elle, contourne toutes vos règles de sécurité : elle est faite pour tourner uniquement sur un serveur, jamais dans le code envoyé au visiteur.

Quand un outil no-code place cette clé dans le frontend ce qui arrive plus souvent qu'on ne le croit vous offrez à chaque visiteur un accès administrateur complet à votre base. C'est la faille la plus grave, et la plus indiscutable.

Comment vérifier : cherchez la chaîne service_role dans le code de votre site. Elle ne doit apparaître nulle part côté client.

3. Les politiques trop permissives

Une faille sournoise, parce qu'elle rassure faussement. Le RLS est activé, une politique existe mais elle est écrite ainsi :

create policy "acces" on commandes
  using ( true );

using ( true ) signifie « autorise tout le monde ». La règle est là, elle donne l'impression d'une protection, mais elle n'en est pas une. La bonne version relie chaque ligne à son propriétaire :

create policy "acces" on commandes
  using ( auth.uid() = client_id );

Désormais, chaque utilisateur ne voit que ses propres commandes.

4. L'absence de séparation des rôles

Beaucoup d'apps ont un rôle « administrateur » et un rôle « utilisateur », mais aucune barrière réelle entre les deux. Le statut d'un utilisateur est stocké dans un champ que le frontend peut modifier, ou vérifié uniquement côté navigateur donc contournable.

Résultat : un utilisateur ordinaire peut, avec un peu de curiosité, se hisser au niveau administrateur. La vérification des rôles doit vivre dans la base de données, via les politiques RLS, pas seulement dans l'interface.

5. Les buckets de stockage ouverts et l'absence de sauvegardes

Deux négligences fréquentes. D'abord, les fichiers : les buckets Supabase Storage sont souvent laissés en accès public, ce qui expose factures, pièces d'identité ou documents privés à quiconque devine l'URL. Ensuite, les sauvegardes : beaucoup d'apps n'en ont aucune. Le jour où une donnée est corrompue ou effacée, il n'y a pas de retour en arrière.

Comment savoir où vous en êtes

Vous pouvez faire un premier contrôle vous-même : vérifiez le statut RLS de chaque table dans Supabase, cherchez service_role dans votre code frontend, et testez si vos buckets de fichiers sont publics.

Si vous préférez un regard extérieur, c'est précisément ce que je fais. J'audite les applications Lovable, Bolt et v0 construites sur Supabase, je corrige les failles trouvées en testant que l'app continue de fonctionner exactement comme avant et je documente chaque correction, preuve à l'appui.

Envoyez-moi l'URL de votre application : je vous dis sous 48h ce qui est exposé, gratuitement et sans engagement. Vous déciderez ensuite.

BOB — développeur full-stack & DevOps. Sécurité Supabase pour applications no-code. Français / English.
bobdarnauld@gmail.com · +2376931244211 · https://bob-sec-portfolio.netlify.app/