Je vais effectuer une vérification de sécurité de votre application Lovable ou bolt supabase avant le lancement


À propos de ce service
Traduction automatique
Construit avec Lovck clean, je vous le dirai. Lovable, Bolt ou Cursor. Ça fonctionne. La question ne s’est jamais posée.
La vraie question est ce qu’un inconnu tenant votre clé anonyme peut en lire.
Ces outils génèrent rapidement des politiques, et elles semblent généralement correctes. Mais RLS n’est qu’une couche. En dessous, il y a le système de grants de Postgres, au-dessus, PostgREST, et les fuites se trouvent dans les coutures.
Je gère un POS multi-tenant sur Supabase — 90 migrations, de l’argent réel chaque jour. Trois revues de sécurité ont trouvé six failles réelles, toutes passées à travers des politiques qui, telles qu’elles sont écrites, étaient correctes.
CE QUE JE Vérifie
- Tables avec RLS désactivé ou activé sans politique
- - Fonctions que l’anonyme peut exécuter (révoquer uniquement pour l’anonyme NE ferme PAS cette faille)
- - Vues qui contournent RLS, et celles que PostgREST a rendu modifiables à l’écrit
- - Grants globaux sur les tables, et l’asymétrie que personne n’attend :
- une nouvelle colonne est INTERDITE pour la lecture jusqu’à ce que vous accordiez
- une nouvelle colonne est AUTORISÉE pour l’écriture jusqu’à ce que vous révoquiez
COMMENT JE LE Prouve
Je me connecte en tant qu’utilisateur à faibles privilèges de votre projet, exécute la requête, et vous montre la réponse. Chaque découverte est accompagnée de sa requête et de sa sortie. Après la correction, la même requête est relancée et donne un résultat différent.
Le script en lecture seule que j’utilise est public — exécutez-le vous-même
Découvrez Basel Draz
Supabase RLS and privilege audits
- DeÉgypte
- Membre depuisfévr. 2024
- Temps de réponse moy.11 heures
Langues
Arabe, Anglais
Traduction automatique
Mon portfolio
FAQ
Traduction automatique
Avez-vous besoin de ma base de données de production ?
Non. Un rôle en lecture seule, ou une copie de staging avec le même schéma, suffit. Les vérifications lisent les catalogues, pas vos lignes. Je ne veux pas votre clé de rôle de service et je vous demanderai de ne pas l’envoyer. Seul le package Audit et Fix nécessite un accès en écriture, et uniquement pour les migrations listées dans le rapport.
Je n’ai pas écrit le code moi-même, c’est l’IA qui l’a fait. Est-ce un problème ?
Pas du tout, et vous n’avez pas besoin de comprendre le SQL pour utiliser le rapport. La partie supérieure est écrite en langage clair pour celui qui doit valider, et les requêtes et migrations se trouvent en dessous pour celui qui les applique. Si c’est aussi votre cas, je vous guiderai à travers chacune d’elles.
Et si vous ne trouvez rien ?
Alors le rapport le dit, et vous disposez d’une ligne de base documentée ainsi que la liste de tout ce qui a été testé. Exécutez le script public vous-même avant de commander. S’il revient propre, contactez-moi et je vous dirai honnêtement que vous n’en avez pas besoin.
Est-ce uniquement pour Supabase ?
Les vérifications sont basiques sur Postgres et fonctionnent sur toute base Postgres 15+ utilisant la row level security. Supabase est l’endroit où elles sont le plus nécessaires, car le rôle anonyme et PostgREST exposent des choses auxquelles on ne s’attend pas. Je signe aussi un NDA sur demande, et vos découvertes n’apparaissent jamais dans mes écrits publics.

