J'auditerai la sécurité de votre supabase, les politiques RLS, les fonctions et l'authentification

Votre clé anon Supabase est publique. N'importe qui peut la copier depuis votre application et appeler directement votre base de données. La seule chose qui les sépare des données de vos utilisateurs, ce sont vos politiques RLS, vos autorisations de fonctions et vos paramètres d'authentification. Je vérifie ces trois éléments.

Si votre application a été créée avec Lovable, Bolt ou Cursor, cela importe encore plus : après la divulgation de Lovable en avril 2026, les propriétaires ont été invités à faire pivoter leurs clés et à vérifier manuellement la RLS sur chaque table.

Ce que vous obtenez :

• Chaque constat classé de critique à information, avec la requête exacte qui le prouve, l’impact et la requête SQL pour le corriger.
• Un tableau de bord par domaine : couverture RLS, conception des politiques, exposition des fonctions, authentification, stockage.
• Des tests en direct utilisant uniquement votre clé anon, pour que les résultats soient concrets, pas théoriques.
• Une liste claire de ce qui n’a pas été testé.

J’ai créé un SaaS de clinique multi-tenant sur Supabase avec des helpers RLS et SECURITY DEFINER, et j’utilise la même checklist sur mon propre projet.

Je ne demande jamais votre clé de service-role. L’accès SQL en lecture seule et la clé anon suffisent. Envoyez-moi la référence de votre projet et le lien du repo, je confirmerai la portée avant votre commande.