Votre base Supabase est-elle ouverte ? Ce qu'il faut vérifier

Supabase est un service de base de données très utilisé, et beaucoup d'outils d'IA s'en servent pour stocker les données d'une application. C'est un bon outil, qui offre de vrais moyens de protéger vos utilisateurs. Mais l'un d'eux doit être bien réglé, et dans les applications construites vite, il l'est souvent mal. Résultat : une base que n'importe qui peut lire avec quelques lignes de code, alors que l'application paraît tout à fait normale à l'écran. Cet article explique la sécurité au niveau des lignes avec des mots simples, pourquoi elle manque si souvent, comment vérifier votre propre projet et quoi faire si vous trouvez un problème. Il approfondit un seul point. Pour la liste complète des vérifications, voyez notre checklist sécurité pour une application créée avec l'IA.

Comment votre application parle à Supabase

Dans une application classique, le navigateur demande les données à votre serveur, et le serveur les demande à la base. Beaucoup d'applications Supabase sautent cette étape du milieu. Le code qui tourne dans le navigateur parle directement à la base de données, par l'API de Supabase (l'adresse à laquelle l'application envoie ses demandes).

Pour cela, le code du navigateur contient deux choses : l'adresse de votre projet et une clé publique, appelée clé anon (les projets plus récents l'appellent parfois clé publishable). N'importe qui peut ouvrir les outils de développement du navigateur et voir les deux. C'est normal. Supabase l'a conçu ainsi, et cette clé est faite pour être publique. La vraie question est ce que quelqu'un peut faire avec.

Ce qu'est la sécurité au niveau des lignes

La sécurité au niveau des lignes, ou RLS (row level security), est une fonction de Postgres, la base de données qui se trouve dans Supabase. Elle permet d'écrire des règles, appelées policies, qui disent qui peut lire, ajouter, modifier ou supprimer chaque ligne d'une table. Une ligne, c'est un enregistrement : une commande, un message, un profil client.

Imaginez votre application comme un immeuble. La clé publique ouvre la porte d'entrée, et chaque utilisateur en a une copie. La RLS, c'est la serrure de chaque appartement. Avec les serrures, une personne dans le hall ne peut entrer que dans son propre appartement. Sans elles, toutes les portes sont ouvertes à quiconque entre dans l'immeuble.

Une bonne règle pour une table de commandes dit, en clair : un utilisateur connecté peut lire une commande seulement si elle lui appartient. Si la RLS est activée et qu'une table n'a aucune règle, personne ne peut la lire avec la clé publique. C'est sûr, mais votre application affichera des écrans vides tant que les bonnes règles n'existent pas.

La clé publique de votre application n'est pas la fuite. Une table sans serrure, si.

Pourquoi les applications créées avec l'IA sont souvent lancées ouvertes

• Les tables créées en SQL démarrent sans RLS. Les outils d'IA créent souvent les tables en écrivant du code SQL (le langage qui sert à construire une base de données). Une table créée de cette façon a la RLS désactivée, sauf si le code l'active.
• Des règles écrites pour faire disparaître une erreur. Quand la RLS bloque une demande, l'application affiche une liste vide ou une erreur d'autorisation. La solution la plus rapide, pour une personne comme pour une IA, est une règle qui autorise tout. L'erreur disparaît, la protection aussi.
• Des règles qui vérifient la connexion, pas le propriétaire. Une règle comme « tout utilisateur connecté peut lire toutes les lignes » paraît sûre. Mais n'importe qui peut créer un compte, donc en pratique, cela veut dire tout le monde.
• Des tests avec un seul compte. Si vous êtes le seul utilisateur, vous ne voyez que vos propres données, avec ou sans règles. Le problème reste invisible jusqu'à ce qu'une deuxième personne regarde.
• La clé secrète dans le navigateur. Supabase fournit aussi une clé service role (les projets plus récents l'appellent parfois clé secrète). Elle ignore complètement la RLS et ne doit servir que dans le code du serveur. Si elle se retrouve dans le code du navigateur, vos règles ne servent à rien : quiconque la copie peut tout lire et tout modifier.

Soyons justes avec ces outils : les outils d'IA font beaucoup de choses bien sur ce point, et certains créent désormais des règles et signalent les tables ouvertes. Cela aide. Mais une règle qui existe n'est pas toujours une règle juste, et un avertissement n'aide que si quelqu'un le lit.

Comment vérifier dans le tableau de bord

Il vous faut un accès à votre projet Supabase. Vous n'avez pas besoin d'écrire du code.

• Regardez chaque table. Ouvrez le Table Editor et parcourez les tables du schéma public (l'endroit par défaut où se trouvent les tables de votre application). Le tableau de bord signale par un avertissement les tables dont la RLS est désactivée. Toute table avec cet avertissement peut être lue par quiconque possède votre clé publique.
• Lisez le Security Advisor. C'est une page du tableau de bord qui liste les problèmes de sécurité détectés, comme des tables sans RLS. Lisez chaque avertissement. Si vous n'en comprenez pas un, notez-le pour quelqu'un qui pourra vous l'expliquer.
• Lisez les règles de chaque table. Pour chaque table avec la RLS activée, ouvrez ses policies. Cherchez deux signaux d'alerte : une règle dont la condition est simplement « true », ce qui veut dire tout le monde, et une règle de lecture pour tous les utilisateurs connectés qui ne vérifie jamais à qui appartient la ligne. Une bonne règle compare en général le propriétaire de la ligne avec la personne connectée. Dans le code, cela ressemble souvent à auth.uid() = user_id.
• Vérifiez le stockage des fichiers. Les photos et les documents sont rangés dans des buckets (des dossiers pour les fichiers). Dans un bucket public, n'importe qui ayant le lien d'un fichier peut l'ouvrir. C'est très bien pour des photos de produits, pas pour des factures ou des pièces d'identité.
• Demandez où la clé secrète est utilisée. Posez la question à la personne qui construit l'app, ou à votre outil d'IA : la clé service role est-elle utilisée quelque part dans le code qui tourne dans le navigateur ? La seule bonne réponse est non.

Faites ensuite le test des deux comptes décrit dans la checklist : connectez-vous avec un utilisateur et essayez d'ouvrir les données d'un autre. Ces vérifications trouvent la plupart des portes ouvertes, mais pas toutes. Certaines parties de la base, comme les vues et les fonctions, peuvent contourner la RLS quand elles sont réglées d'une certaine façon. Celles-là demandent quelqu'un qui sait lire le SQL.

Que faire si vous trouvez un problème

• Agissez aujourd'hui. Une table ouverte avec des données personnelles est la correction la plus urgente de votre application. Elle passe avant toute nouvelle fonction.
• Préparez les règles avant d'activer la RLS. Activer la RLS sans règle ferme la table, et votre application n'affiche plus ces données. Écrivez d'abord les bonnes règles. Pour une table de données privées, une courte coupure de l'application vaut quand même mieux qu'une fuite.
• Remplacez une clé secrète exposée. Si la clé service role s'est un jour trouvée dans le code du navigateur ou dans un dépôt de code public, créez une nouvelle clé et désactivez l'ancienne. Certaines parties de l'application devront peut-être être mises à jour pour utiliser la nouvelle.
• Cherchez ce qui a été exposé. Quelles tables, quel type de données, et depuis quand. Supabase garde les journaux des demandes pendant une durée limitée, ce qui peut aider.
• Pensez à vos obligations légales. Si des données personnelles de personnes en Europe ont pu être vues par d'autres, le RGPD peut vous obliger à le signaler à l'autorité de protection des données dans les 72 heures après l'avoir découvert. Ceci n'est pas un conseil juridique. En cas de doute, demandez à un avocat.
• Vérifiez de nouveau après la correction. Refaites le test des deux comptes et relisez le Security Advisor. Ne faites pas confiance à une correction que vous n'avez pas testée.

Pourquoi un regard extérieur aide

La personne qui écrit une règle a tendance à tester le cas qu'elle avait en tête. Une IA fait pareil : elle écrit des règles qui ont l'air justes et qui répondent à la demande, puis elle passe à la suite. Personne ne vérifie le cas auquel personne n'a pensé.

Une personne qui relit fait l'inverse. Elle essaie de lire vos données comme le ferait un inconnu, avec seulement la clé publique, en appelant la base directement au lieu de passer par vos écrans. Elle lit chaque policy, chaque vue et chaque fonction, et vérifie où chaque clé est utilisée. C'est un petit travail comparé au coût d'une fuite, et vous obtenez une liste claire, classée par niveau de risque. Chez Swipe Up, les règles de la base de données sont la première chose que nous vérifions quand nous finissons une application créée avec l'IA. Pour un premier avis par vous-même, notre test de lancement gratuit montre en deux minutes les points encore ouverts.

En résumé

Supabase vous donne les serrures. Il reste à les poser. Activez la RLS sur chaque table, assurez-vous que chaque règle limite l'utilisateur à ses propres données, et gardez la clé secrète sur le serveur. Passez ensuite au reste de la liste : connexion, paiements, envoi de fichiers et limites. Les problèmes y prennent d'autres formes, mais ils ont la même cause, que nous décrivons dans pourquoi un prototype IA casse avec de vrais utilisateurs.