Reeve Votre appli Supabase est-elle sûre ?
Supabase est la base de données et le back-end derrière une énorme part des applis vibe-codées. C'est puissant et sûr quand c'est bien configuré — mais quelques réglages décident si vos données sont privées ou ouvertes au monde entier, et ils sont faciles à manquer.
Reeve vérifie ceux qui comptent depuis l'extérieur, gratuitement, et explique ce qu'il trouve en langage clair. Aucune installation, aucun accès à votre projet — nous regardons seulement ce qui est déjà accessible, et nous ne lisons jamais vos données réelles.
Collez le lien de votre appli. Environ 20 secondes. Voyez votre note sans inscription.
Ce qui peut réellement mal tourner avec Supabase
Rien de tout cela ne signifie que vous avez fait une erreur — ce sont les failles habituelles quand on avance vite. Voici ce qui vaut la peine d'être vérifié :
Row Level Security (RLS) désactivée
Le RLS est la règle de Supabase qui détermine qui peut lire ou modifier chaque ligne d'une table. Avec la clé publique « anon » — qui est censée être dans votre appli — n'importe qui peut interroger directement votre base de données. Le RLS est ce qui l'empêche de voir des lignes qui ne lui appartiennent pas. S'il est désactivé, une table peut être entièrement lisible, voire modifiable, par tous. C'est le réglage Supabase le plus important, et Reeve le vérifie en comptant les lignes, jamais en les lisant.
Une clé service_role qui a fuité
Supabase vous donne deux clés. La clé « anon » est publique par conception et sûre dans le navigateur. La clé « service_role » contourne toutes vos règles de sécurité et ne doit vivre que sur un serveur. Si elle se retrouve un jour dans le code front-end de votre appli, quelqu'un peut faire n'importe quoi avec vos données. Reeve décode les clés qu'il trouve et vous dit exactement laquelle est exposée — la « anon » sûre reçoit une coche verte, « service_role » est une alerte rouge.
Espaces de stockage publics
Les fichiers que les gens téléversent vivent dans des « espaces » (buckets) de Supabase Storage. Un espace réglé sur public signifie que n'importe qui peut lister et télécharger ce qu'il contient — les téléversements privés peuvent donc devenir visibles par tous. Reeve vérifie si vos espaces sont listables ; il ne télécharge jamais les fichiers de qui que ce soit.
Votre API ouverte à n'importe quel site (CORS)
Supabase donne à votre base de données une adresse web (via PostgREST). Combinée à un réglage de partage trop permissif, un autre site pourrait appeler vos données depuis le navigateur d'un visiteur. Reeve vérifie si vos points d'accès répondent aux inconnus et à d'autres sites — sans jamais s'en servir pour modifier quoi que ce soit.
Tables et points d'accès exposés sans règles
Chaque table que vous créez est accessible via l'API de Supabase — c'est voulu, et le RLS est censé la garder. Mais une nouvelle table ajoutée à la hâte, avant que ses règles ne soient définies, peut être brièvement (ou durablement) ouverte. Reeve vérifie ce qui est réellement accessible depuis l'extérieur.
Clés ou configuration laissées dans l'appli déployée
Au-delà des propres clés de Supabase, les applis transportent souvent d'autres réglages et secrets dans leur code front-end ou dans un .env exposé. Reeve lit le code chargé de votre appli et vérifie les fichiers de configuration accessibles, puis vous dit quelles valeurs sont sûres à rendre publiques et lesquelles ne le sont pas.
Ce que Reeve est — et n'est pas
Reeve est une vérification gratuite, en lecture seule, depuis l'extérieur — comme un inspecteur qui essaie les portes sans entrer. C'est rapide et ça repère les erreurs courantes à fort impact. Ce n'est pas un audit de sécurité complet, et une note propre n'est pas une garantie — elle signifie que les portes évidentes sont fermées. Tout ce que fait Reeve est passif : il compte les lignes plutôt que de les lire, et ne télécharge jamais vos fichiers.
Supabase vous donne de vrais outils de sécurité — un Security Advisor et un linter de base de données qui signalent les problèmes de RLS et d'exposition directement dans le tableau de bord — et ils valent vraiment la peine d'être utilisés. Ce que Reeve ajoute : la plupart des gens qui construisent sur Supabase vivent dans leur créateur d'applis, pas dans l'éditeur SQL, et le conseiller parle le langage des développeurs. Reeve vérifie toute votre appli depuis l'extérieur — comme un attaquant atteindrait vos données — et explique ce qu'il trouve en mots simples. Et si vous préférez ne pas la surveiller vous-même, nous le pouvons.
Vous voulez que ce soit géré, pas seulement vérifié ?
Reeve Care continue de surveiller votre appli, sauvegarde vos données et vous aide à réparer les choses quand elles cassent — pour que vous puissiez continuer à créer au lieu de vous inquiéter.
En savoir plus sur Reeve CareDes questions, des réponses honnêtes
Qu'est-ce que le RLS de Supabase et en ai-je vraiment besoin ?
Le RLS (Row Level Security) décide qui peut voir ou modifier chaque ligne de vos tables. Comme votre appli expédie une clé publique « anon » capable d'interroger directement la base de données, le RLS est ce qui empêche les données d'un utilisateur d'être visibles par tous. Oui — pour toute table contenant de vraies données, vous en avez besoin. Reeve vérifie s'il est activé, sans lire vos données.
La clé anon de Supabase est-elle sûre à exposer ?
Oui — la clé « anon » est conçue pour vivre dans votre front-end, et à elle seule elle ne fait que ce que vos règles RLS autorisent. La clé qui ne doit jamais être exposée est la clé « service_role », qui ignore toutes les règles. Reeve décode les clés de votre appli et vous dit laquelle est laquelle.
Que se passe-t-il si ma clé service_role fuite ?
La clé service_role contourne toutes les règles de sécurité, donc quiconque la possède peut lire, modifier ou supprimer toutes vos données. Si elle est dans votre code front-end, considérez-la comme compromise : renouvelez-la dans le tableau de bord Supabase et déplacez-la vers un serveur. Reeve signale une clé service_role exposée comme un problème critique.
Reeve peut-il vérifier mon Supabase sans mon mot de passe de base de données ?
Oui. Reeve n'utilise que ce que votre appli expose déjà publiquement — la même clé anon et les mêmes points d'accès que le navigateur de n'importe quel visiteur utilise. Il n'a jamais besoin de votre mot de passe de base de données, ne se connecte jamais en tant qu'administrateur et ne lit ni ne télécharge jamais vos lignes ou fichiers.
Vous avez créé votre appli dans un outil précis ? Voici le même topo honnête pour :
Vérification externe automatisée, pas un audit complet. L'absence de problème n'est pas une garantie de sécurité.