Aller au contenu

Bases de la sécurité

Qui peut lire votre base Supabase ? Nous avons testé 3 680 apps

N'importe qui peut-il lire votre base de données Supabase sans se connecter ? Nous avons scanné 30 998 apps en ligne créées avec des builders IA.

Vlad Tkachenko8 min de lecture

En bref

  • N'importe qui peut-il lire votre base de données Supabase sans se connecter ? Sur 2 096 des 3 680 apps où la vérification a pu aller au bout (57 %), au moins une table a répondu oui.
  • Ce n'est pas automatiquement une fuite. Certaines tables sont faites pour être publiques. Mais 394 de ces apps avaient une table ouverte au nom de personnes : users, profiles, customers, orders.
  • Ce dont on vous avertit sans cesse, une clé secrète posée dans l'app, est apparu 3 fois sur 30 998 apps. La table ouverte, elle, est le cas courant.

Votre app a un écran de connexion. Derrière lui se trouvent vos utilisateurs, leurs messages, peut-être leurs commandes. Cela paraît privé, et il n'y a aucun moyen évident de savoir si ça l'est vraiment, parce que la console Supabase n'est pas un endroit où vous avez jamais eu besoin d'aller.

Alors nous sommes allés le mesurer sur les apps des autres. En août 2026, nous avons scanné 30 998 apps en ligne publiées depuis Lovable, Base44, Replit, v0 et Bolt, en posant à chacune une seule question : n'importe qui peut-il lire votre base de données Supabase sans se connecter ?

Pour 2 096 des 3 680 apps où nous avons obtenu une réponse nette : oui.

Et voici ce que ratent à la fois la version alarmante de cette histoire et la version rassurante. Une table ouverte n'est pas automatiquement une fuite : beaucoup de tables sont faites pour être lues par tout le monde. Quelle table c'est décide de tout, et seule la personne qui a construit l'app peut répondre. C'est aussi pour cela que personne ne le remarque : l'app fonctionne parfaitement dans les deux cas.

Qui peut lire votre base de données Supabase ?

Pour plus de la moitié des apps que nous avons pu vérifier, tout le monde : au moins une table a renvoyé des lignes à une requête ne portant aucune connexion.

Que ce soit possible n'a rien à voir avec quoi que ce soit de cassé. Votre app parle à Supabase depuis le navigateur de votre visiteur, elle transporte donc une clé que chaque visiteur peut lire, et cette clé est faite pour être publique. Elle nomme votre projet. À elle seule, elle n'accorde rien.

Ce qui décide si un inconnu obtient vos données, c'est Row Level Security : une règle sur chaque table qui dit qui peut lire quelles lignes. Sans règle, la clé est la seule chose entre internet et cette table, et la clé est écrite dans votre page.

C'est cela que nous mesurions. Pas si une clé était visible (elle l'est toujours), mais ce que fait la base de données quand quelqu'un s'en sert.

De quoi ces 57 % sont-ils une part ?

D'une base que nous avons resserrée trois fois, et ce resserrement compte plus que le titre.

Ce que nous avons comptéApps
Apps en ligne scannées et classées30 998
Nomment un projet Supabase dans la page8 435
Table confirmée et réponse obtenue3 680
Au moins une table lisible sans connexion2 096
…et l'une d'elles portait un nom de personnes394
Chaque barre est mesurée sur le même total. Les 57 % sont une part des 3 680 apps que nous avons réellement pu vérifier, pas de toutes celles que nous avons scannées.

Trois choses que nous n'avons pas faites. Chacune pousse le chiffre réel dans un sens ou dans l'autre, et mérite d'être dite plutôt qu'enterrée.

Nous n'avons interrogé que des noms de tables visibles ou devinables. Supabase ne laisse plus une clé publiable lister les tables d'un projet ; nous avons donc lu les noms qu'une app mentionne dans son propre code et ajouté deux douzaines de noms ordinaires, plafonnés à trente par app. Une app dont les tables portent un nom auquel nous n'avons pas pensé nous paraît propre et ne l'est peut-être pas.

Nous avons compté des lignes, jamais lues. Chaque sonde a demandé à la base combien de lignes elle remettrait, et s'est arrêtée là. Les données de personne n'ont été téléchargées, et aucune app n'est nommée dans cet article ni dans quoi que ce soit que nous publions.

Presque toutes les apps que nous avons pu vérifier étaient des apps Lovable. Elles constituent la plus grande part de ce que nous avons scanné et sont les plus susceptibles de nommer leur projet Supabase dans la page ; lisez donc ceci comme une mesure des apps Lovable avec Supabase et non de tous les builders. Là où la vérification n'a pas pu aller au bout, nous avons enregistré qu'elle n'a pas abouti. Une app que nous n'avons pas pu vérifier est inconnue, pas propre.

Une table ouverte n'est pas automatiquement un trou

De l'extérieur, une table que tout le monde peut lire a exactement la même allure qu'elle contienne votre catalogue de produits ou vos clients. La réponse est la même. Seul le nom diffère.

Même requête, même réponse, verdicts opposés. Seule la personne qui a construit l'app sait lequel de ces deux cas est sa table ouverte.

C'est pourquoi nous coupons le constat en deux. Dans 394 de ces apps, l'une des tables lisibles portait un nom tiré d'une courte liste qui signifie pour nous des personnes : users, profiles, customers, orders, messages, invoices. C'est un inconnu qui lit vos clients, et cela se corrige aujourd'hui.

Les 1 702 autres, nous ne pouvons pas les juger de l'extérieur, et aucun autre scanner ne le peut non plus. Une table posts peut être un blog public ou des notes privées. Vous savez laquelle. Personne qui regarde votre app depuis internet ne le sait.

Si vous préférez ne pas deviner pour la vôtre, notre scan gratuit examine votre site en ligne depuis l'extérieur et vous dit quelles tables ont répondu. Il prend une vingtaine de secondes et ne demande aucun compte : scanner votre app.

Pourquoi cela arrive à des apps que personne n'a ouvertes exprès

Parce que le correctif qui remet une app cassée en marche est en général celui qui ouvre la table.

La séquence est la suivante. Row Level Security est activé, par vous ou par le builder. Votre app cesse aussitôt d'afficher des données, car activé sans règles signifie que la base refuse tout le monde, vous compris. Vous collez l'erreur à votre assistant, il écrit une politique autorisant chaque requête, et l'app refonctionne. Ensuite, plus rien n'a l'air anormal.

Cette politique-là est celle que nous trouvons. Le tableau de bord signale la table comme protégée, puisque l'interrupteur est activé et qu'une politique existe. L'article sur pourquoi Row Level Security activé ne veut pas dire protégé parcourt les quatre états possibles d'une table et la façon de reconnaître le vôtre.

La fuite dont on vous avertit était la plus rare

Sur l'ensemble des 30 998 apps, une clé secrète Supabase posée dans le navigateur (la clé qui ignore chaque règle que vous avez écrite) est apparue 3 fois.

C'est la fuite dont les propriétaires d'app entendent parler sans arrêt, et celle que nous avons trouvée le moins souvent. Elle est grave quand elle survient, et il vaut la peine de savoir la repérer, mais l'inquiétude dépensée là surveille une porte presque toujours fermée. L'ouverture ordinaire dans ces apps est une table banale sans aucune règle.

Comment vérifier votre propre app

Deux endroits où regarder dans votre base de données Supabase, et une façon de la voir depuis l'endroit où se tient un inconnu.

Ouvrez le Security Advisor dans votre tableau de bord Supabase. Il liste chaque table dont Row Level Security est désactivé, la version la plus nette de ce problème. Supabase le signale bien, et si votre projet figure sur cette liste vous avez votre réponse sans lire une ligne de SQL.

Lisez ensuite les politiques de toute table contenant des personnes. Le Security Advisor ne peut pas décider si une politique permissive est intentionnelle, car pour un catalogue de produits elle serait correcte. Ouvrez la table, regardez la politique et voyez si elle nomme une condition ou si elle autorise tout le monde.

Ou vérifiez-le de l'extérieur, là où vit le risque. Un inconnu n'ouvre pas votre tableau de bord. Notre scan gratuit envoie la même requête anonyme qu'une personne extérieure et rapporte quelles tables ont répondu : scanner votre app, sans compte et sans installation.

Que faire d'une table qui ne devrait pas être lisible

Que faire

  • Commencez par les tables qui contiennent des personnes. users, profiles, customers, orders et messages sont là où vivent les données de quelqu'un d'autre, et elles valent une soirée.
  • Écrivez la règle avant d'élargir quoi que ce soit d'autre. Une politique qui nomme une condition (cette ligne appartient à cet utilisateur connecté) est ce qui rend la clé publiable de votre app inoffensive là où elle est.
  • Vérifiez la politique, pas le bouton. Activé avec une règle qui autorise tout le monde a exactement la même allure, vu de l'extérieur, que désactivé, et votre tableau de bord affiche le premier cas comme protégé.
  • Laissez tranquilles les tables réellement publiques. Qu'une liste de produits ou un article publié soit lisible est correct, et le couper casse votre app sans rien gagner.
  • Après le changement, testez comme le ferait un inconnu. Que votre app affiche la bonne chose prouve ce que votre app demande, pas ce que votre base remettrait.

Vérifier cela une fois, c'est une soirée. Garder la réponse vraie le mois prochain, c'est la part qui ne tient pas dans une soirée, et c'est pour cela que nous avons construit Reeve Care. Il relance cette même vérification sur votre app à intervalles réguliers et vous écrit quand la réponse se dégrade, parce qu'une table fermée en mars et ouverte en juin, personne ne le remarque depuis l'intérieur de sa propre app.

Les deux tâches : la vérification se relance à intervalles réguliers, et une copie de votre base quitte votre compte Supabase et est relue avant d'être comptée.

Il conserve aussi ses propres sauvegardes de votre base de données Supabase, prises à intervalles réguliers, stockées hors de votre compte Supabase et relues pour vérification avant d'être comptées, avec une restauration qui capture l'état actuel avant de rejouer quoi que ce soit. Cette seconde moitié compte ici parce que nous ne vérifions jamais que la lecture. La même politique permissive peut autoriser l'écriture, et un inconnu qui écrit dans votre table, c'est la version qui la vide, et à ce moment-là, une copie d'avant est la seule chose qui remet les lignes en place. Care couvre votre base de données, et les fichiers téléversés dans Storage dès que vous les connectez, sur Supabase et non sur tous les types de base : ce qu'il surveille et ce qu'il coûte.

Si vous préférez avancer par liste, la checklist de sécurité en 10 minutes couvre ceci en même temps que les autres points à refermer dans une app fraîchement lancée. Et si une table est restée ouverte un moment, ce que vous pourrez défaire ensuite dépend entièrement de ce que vous sauvegardiez.

FAQ

Comment savoir si n'importe qui peut lire ma base de données Supabase ?

Deux vérifications règlent l'essentiel. Dans votre tableau de bord Supabase, ouvrez le Security Advisor : il liste chaque table dont Row Level Security est désactivé, et celles-là sont lisibles par quiconque détient la clé livrée dans votre app. Ouvrez ensuite les politiques de toute table contenant des personnes, car une table peut passer la première vérification et rester ouverte : une politique qui autorise tout le monde est activée, valide, et s'affiche comme protégée dans le tableau de bord. Si vous préférez le voir de l'extérieur, notre scan gratuit lit votre site en ligne comme le ferait un inconnu.

Est-ce grave qu'une de mes tables soit lisible par tout le monde ?

Cela dépend de la table, et vous êtes la seule personne à pouvoir en décider. Une liste de produits, d'articles publiés ou de lieux sur une carte est faite pour être lue par tous, et une politique qui l'autorise est correcte. Le même réglage sur une table d'utilisateurs, de commandes ou de messages signifie que des inconnus lisent vos clients. Demandez-vous si vous afficheriez le contenu de cette table sur une page publique, et laissez la réponse décider.

J'ai activé Row Level Security. Mes tables sont-elles protégées pour autant ?

Pas à elle seule. L'interrupteur et les règles sont deux choses distinctes : activé sans aucune règle bloque tout le monde, y compris votre propre app, et activé avec une règle permissive ne bloque personne. La règle écrite quand une app casse après l'activation de Row Level Security est en général celle qui autorise n'importe quelle requête de n'importe qui, ce qui remet l'app en marche et laisse la table ouverte. Lisez la politique de la table, pas le bouton.

Mon app a un écran de connexion. Cela ne tient-il pas les gens à l'écart de la base ?

Non. Votre écran de connexion décide de ce que votre app affiche. Il ne décide pas de ce que votre base de données remet, car une requête n'a pas besoin de venir de votre app : la clé que votre app transporte est lisible par n'importe quel visiteur et peut être utilisée directement contre votre base. Ce qui décide de la réponse, c'est Row Level Security sur chaque table.

Que faire en premier si je trouve une table que des inconnus peuvent lire ?

Corrigez la politique de cette table avant tout le reste, puis regardez ce qui était atteignable pendant qu'elle était ouverte. Commencez par les tables qui contiennent des personnes, puisque ce sont celles où se trouvent les données de quelqu'un d'autre. Si la table était ouverte et contient des données personnelles, vérifiez si vos règles locales vous obligent à prévenir quelqu'un ; c'est une question pour un juriste, pas pour un scanner.

Écrit par

Vlad Tkachenko

Fondateur de Reeve

Je passe mes journées à examiner des applications créées avec Lovable, Bolt, v0, Cursor et Replit, et la courte liste d'erreurs qui y reviennent sans cesse.

En savoir plus sur l'auteur

À lire ensuite

Vous ne savez pas où en est votre propre application ?

Lancez une analyse gratuite et obtenez une note claire de A à F en une vingtaine de secondes. Sans compte, sans carte.

Analyser mon application

Vérification externe automatisée, pas un audit complet. L'absence de problème n'est pas une garantie de sécurité.