Reeve Bases de la sécurité
Qu'est-ce que Supabase ? La base que votre builder a choisie
Qu'est-ce que Supabase : la base de données, la connexion et le stockage de fichiers de votre app. Les règles sur qui lit vos lignes sont à vous.
En bref
- Qu'est-ce que Supabase ? C'est là que votre app garde tout ce qu'elle doit retenir : vos utilisateurs et leurs mots de passe, les lignes derrière chaque liste et les fichiers que les gens envoient.
- Votre builder l'a presque certainement choisi pour vous pendant qu'il créait le projet, et c'est pour ça que personne ne vous a jamais montré ce qu'il y a dedans.
- Supabase tient les machines. Les règles disant qui peut lire quelles lignes sont à vous, et sur une table créée en SQL elles démarrent désactivées.
Votre app fonctionne. Quelque part dans ses réglages, dans un mail au sujet d'une facture ou au milieu d'un message de Lovable, il y a le mot Supabase. Tôt ou tard il faut découvrir ce que c'est, et la raison est rarement la curiosité : un scan a mentionné votre projet Supabase, un développeur a demandé sur quel plan vous êtes, ou votre app a cessé d'enregistrer et la réponse est là-dedans.
Alors : qu'est-ce que Supabase. Toutes les autres explications répondent à ça comme à un choix entre outils, qui est la question que se pose un développeur avant de démarrer un projet. Vous n'avez jamais fait ce choix. Votre builder l'a fait dans les secondes qu'a pris la création du projet, et c'est pour ça que personne ne vous a jamais fait visiter la chose qui détient aujourd'hui toutes les données de vos utilisateurs.
Voici la version pour quelqu'un qui en a déjà un.
Qu'est-ce que Supabase, en une phrase ?
C'est là que votre app garde tout ce qu'elle doit retenir.
Vos utilisateurs et leurs mots de passe. Les lignes derrière chaque liste que votre app affiche. Les images et documents que les gens envoient. Quand quelqu'un s'inscrit à deux heures du matin, cet enregistrement atterrit dans votre projet Supabase et il y est encore une fois l'onglet refermé.
Dessous il y a Postgres, une base de données en production depuis les années quatre-vingt-dix et qui ne vous réservera pas de surprise. Ce que Supabase ajoute, c'est tout ce qu'il y a autour : un système de connexion, un endroit pour les fichiers et un moyen pour votre app de demander des données directement depuis le navigateur sans que vous écriviez un serveur.
C'est sur ce dernier point que vos propres décisions commencent.
Les quatre morceaux que vous avez réellement
Quatre, et votre app en utilise probablement au moins deux.
- La base de données. Des tables de lignes : vos utilisateurs, vos commandes, vos publications. La partie que les gens désignent quand ils disent "Supabase".
- Auth. S'inscrire, se connecter, réinitialiser un mot de passe. Si votre app a des comptes, ils vivent ici.
- Storage. Les fichiers envoyés, dans des buckets nommés. Photos de profil, pièces jointes, exports.
- Edge functions. De petits bouts de code qui tournent sur les serveurs de Supabase plutôt que dans le navigateur de votre visiteur. Votre app n'en a peut-être aucune, et il y a quand même une bonne raison de s'y intéresser, plus bas.
Votre tableau de bord en liste plus que ces quatre. Laissez le reste tranquille jusqu'à ce que ce que vous construisez en ait besoin.
De quoi s'occupe Supabase, et qu'est-ce qui est à moi ?
Supabase s'occupe des machines. Vous vous occupez des règles.
La ligne est plus haute que ne le supposent la plupart des gens. Voyez le projet comme un local que vous louez. Le propriétaire entretient le bâtiment, l'électricité et la porte d'entrée. Ce que vous gardez à l'intérieur, et qui vous laissez entrer, n'a jamais été à lui d'en décider.
| Ce que Supabase fait tourner | Ce qui est à vous |
|---|---|
| Les serveurs, la version de Postgres et les mises à jour | Quelles lignes chaque visiteur a le droit de lire |
| Des sauvegardes quotidiennes de votre base sur les plans payants, gardées une semaine | S'il existe une copie quelque part que votre propre projet ne peut pas atteindre |
| Le chiffrement de vos données sur ses disques et en route vers votre app | Qui détient vos clés, et laquelle est dans votre app |
| Le maintien en état du système de connexion | Quels fichiers d'un bucket n'importe qui peut lister |
Rien dans la colonne de gauche ne tombe en panne discrètement : si Supabase a une panne, vos utilisateurs vous le disent en quelques minutes. La colonne de droite est celle où les choses tournent mal sans un bruit, parce que rien ne casse. Votre app continue de fonctionner exactement comme hier.
Mes données Supabase sont-elles privées par défaut ?
Cela dépend de la façon dont chaque table a été créée, et la façon dont un builder les crée est celle qui les laisse ouvertes.
La documentation de Supabase est directe là-dessus. Elle indique que le Table Editor active Row Level Security pour vous quand vous créez une table dans le Dashboard, et que lorsque vous créez une table en SQL c'est à vous de l'activer. Row Level Security est le réglage par table qui décide quelles lignes un visiteur peut lire. Votre builder écrit du SQL, donc une table créée par votre builder arrive avec ce réglage désactivé.
La phrase suivante de la même page dit ce que cela laisse derrière : une table
du schéma public est joignable par la Data API, et tant que vous n'avez pas
activé Row Level Security et écrit une politique, n'importe qui détenant la clé
publishable de votre projet peut en lire et en écrire toutes les lignes. Cette
clé est dans votre app, là où elle a sa place, et tout le monde peut la lire
depuis la page.
Donc la serrure de chaque table est ce qu'il faut aller regarder, et elle se pose par table plutôt que par projet. Comment l'activer, et ce qu'est une politique est le pas à pas. Nous avons aussi compté à quelle fréquence elle manque : 2 096 des 3 680 apps dont la base Supabase nous a répondu avaient au moins une table qui livrait ses lignes à un inconnu.
Si vous préférez le voir de l'extérieur plutôt que de parcourir une liste de tables, notre scan gratuit pose à votre projet la question que poserait le navigateur d'un inconnu et vous montre ce qui est revenu. Cela prend environ 20 secondes et ne demande aucun compte : scannez votre app gratuitement.
Où sont vos clés, et laquelle est publique
Votre page de réglages API contient des valeurs de deux sortes, et une seule sorte a sa place dans votre app.
Une clé commençant par sb_publishable_, appelée anon dans un projet plus
ancien, est faite pour être publique et ne fait rien d'autre à elle seule que
dire à quel projet une requête appartient. Une clé commençant par sb_secret_,
appelée service_role dans un projet plus ancien, passe outre toutes les règles
que vous posez. Supabase le dit sans détour : une clé secrète contourne Row
Level Security, elle doit donc rester côté serveur. C'est aussi la bonne raison
de s'intéresser aux edge functions, car une function est l'endroit où un travail
qui a besoin d'une clé secrète peut se faire sans que la clé approche d'un
navigateur.
Où se trouve cette page et ce que fait chaque valeur couvre les emplacements, et quelles clés sont sûres dans un frontend couvre comment distinguer deux clés quasi identiques.
Comment ça reste à vous après la publication
Ce que vous trouvez aujourd'hui décrit l'app d'aujourd'hui. La prochaine table qu'ajoutera votre builder arrivera avec le même réglage par défaut que la précédente, et personne ne vous enverra de message à ce sujet.
Reeve Monitor repose les questions de cet article, à intervalles réguliers :
- les neuf vérifications toutes les heures, sur trois apps au maximum
- si l'app répond, toutes les 60 secondes
- un message quand un résultat change, pour qu'une table ouverte cette nuit vous parvienne avant de parvenir à un inconnu
- un rapport mensuel de ce qui a été vu
Reeve Care garde en plus une copie de votre base de données Supabase. C'est la deuxième ligne de la colonne de droite plus haut, faite pour vous.
- une copie chiffrée de votre base Supabase chaque nuit, rangée là où votre projet ne peut pas aller
- chaque copie vérifiée avant de compter, en comptant les lignes de chaque table
- une restauration en un clic quand vous en avez besoin
- vos fichiers envoyés aussi, dès que vous connectez un accès Storage
- tout ce que fait Monitor
Une table qu'un inconnu peut lire, c'est une chose qu'une vérification trouve. Une migration partie à l'envers, ou un agent ayant accès à votre base, vide la table à la place, et voilà à quoi ça ressemble de l'intérieur.
À vérifier une fois, aujourd'hui
Que faire
- Connectez-vous à Supabase et ouvrez votre propre projet. Le compte est le vôtre même si votre builder l'a créé, et le tableau de bord est l'endroit où se trouve chacune des réponses ci-dessous.
- Lisez la serrure de chaque table dans Authentication → Policies. Une table dont Row Level Security est désactivé livre ses lignes à quiconque détient la clé déjà présente dans votre app, et une politique qui autorise tout le monde compte comme désactivée.
- Ouvrez Settings → API Keys et déterminez lesquelles de vos valeurs sont publishable et lesquelles sont secret. Si une clé secrète a un jour été dans votre app, remplacez-la chez Supabase avant de la retirer du code.
- Regardez vos buckets de storage. Un bucket marqué public liste tous ses fichiers à qui le demande, y compris ceux que votre app ne montre jamais.
- Gardez une copie de la base quelque part que votre projet ne peut pas atteindre, car rien dans la liste ci-dessus ne ramène une table supprimée.
Commencez par les serrures des tables, parce que c'est le seul point de cette liste dont un inconnu peut déjà se servir. Si vous préférez traiter le tout comme une liste, la checklist de sécurité en 10 minutes couvre ce point et les autres réglages à lire sur une app fraîchement publiée. Supabase est-il sûr ? prend l'autre question avec laquelle les gens arrivent, celle de savoir si tout cela était une bonne idée.
FAQ
Qu'est-ce que Supabase, simplement ?
C'est là que votre app garde tout ce qu'elle doit retenir, sur des serveurs entretenus par quelqu'un d'autre. Vos utilisateurs et leurs mots de passe, les lignes derrière chaque liste que votre app affiche et les fichiers que les gens envoient vivent tous dans votre projet Supabase. L'ensemble repose sur Postgres, une base de données en production depuis les années quatre-vingt-dix, avec autour un système de connexion, un stockage de fichiers et un moyen pour votre app de demander des données directement depuis le navigateur.
Supabase est-il une base de données ?
Il en contient une, et il est plus que ça. La base de données est Postgres, et c'est la partie que les gens désignent quand ils disent Supabase. Autour d'elle se trouvent trois autres services que votre app utilise peut-être : Auth pour la connexion, Storage pour les fichiers envoyés et Edge Functions pour du code qui tourne sur les serveurs de Supabase plutôt que dans le navigateur de votre visiteur. Votre tableau de bord en liste plus que ces quatre, et vous pouvez laisser le reste tranquille jusqu'à ce que quelque chose en ait besoin.
Est-ce mon builder qui a choisi Supabase pour moi ?
Presque certainement, oui. Lovable, Bolt, v0, Cursor, Replit et Windsurf se tournent tous vers un Postgres hébergé dès que votre app doit retenir quelque chose, et Supabase est la réponse habituelle. Vous avez peut-être cliqué sur un bouton marqué connecter une base de données, ou votre builder a créé le projet sans demander. Dans les deux cas le compte est le vôtre et vous pouvez vous y connecter, et c'est la première chose à faire.
Quelles parties de la sécurité Supabase sont de mon ressort ?
Supabase tient les serveurs, la version de Postgres, les mises à jour, le chiffrement sur ses disques et le système de connexion lui-même. À vous les règles : quelles lignes chaque visiteur peut lire, quels fichiers d'un bucket sont publics, qui détient vos clés et laquelle se trouve dans votre app, et s'il existe une copie de vos données quelque part que votre projet ne peut pas atteindre. Rien dans la première liste ne tombe en panne discrètement. Tout ce qui est dans la seconde peut rester faux pendant des mois pendant que votre app fonctionne parfaitement.
Mes données Supabase sont-elles privées par défaut ?
Cela dépend de la façon dont chaque table a été créée. La documentation de Supabase indique que le Table Editor active Row Level Security pour vous quand vous créez une table dans le Dashboard, et que lorsque vous créez une table en SQL c'est à vous de l'activer. Un builder écrit du SQL, donc les tables qu'il a créées pour vous arrivent avec ce réglage désactivé. Tant qu'il l'est et qu'aucune politique n'est écrite, Supabase indique que n'importe qui détenant votre clé publishable peut lire et écrire toutes les lignes de cette table, et cette clé est dans votre app, où tout le monde peut la lire.