Supabase permet d’ajouter très vite authentification, base de données, stockage et API à une application moderne. Cette vitesse explique son succès auprès des startups, indie hackers et vibe coders.
Talk Security To Me analyse la surface d’attaque publique de votre application et vous aide à comprendre ce qu’un attaquant externe peut découvrir.
Il n’existe pas un réglage unique qui sécurise un projet. La réponse dépend de la manière dont votre application combine identité, permissions, données, stockage, secrets et services externes.
Ne vous arrêtez pas à « est-ce que mon app fonctionne ? ». Demandez aussi ce qui est accessible sans autorisation et ce que l’application révèle depuis l’extérieur.
Le scan externe ne remplace pas une revue dédiée de chaque politique RLS. Il peut toutefois révéler les services et endpoints publics qui méritent cette investigation.
anon est visible. Est-ce une faille ? Pas automatiquement.La clé publique anon est conçue pour les applications clientes. Votre sécurité ne doit pas dépendre de sa dissimulation, mais de l’authentification et de politiques RLS correctement configurées.
anonSa présence dans le navigateur n’est pas le problème. Ce qu’elle permet de lire ou d’exécuter doit être strictement contrôlé.
service_roleTrès privilégiée, elle contourne les contrôles RLS normaux et ne doit jamais atteindre le navigateur.
Son nom ne la rend pas secrète. Toute valeur intégrée au JavaScript client doit être considérée comme publique.
Il peut appeler directement les services exposés. Vérifiez les données retournées sans authentification, les opérations autorisées, l’application réelle des règles et les informations inutiles révélées par les réponses.
Un bucket public doit l’être intentionnellement. Les utilisateurs ne doivent pas accéder aux fichiers d’autres comptes ni téléverser sans restrictions adaptées.
Connaître l’utilisateur ne détermine pas automatiquement les lignes, fichiers et opérations auxquels il a droit.
Les frontières entre organisations doivent tenir sur les lectures, écritures, API, fichiers et fonctions serveur.
Authentification, autorisation, validation des entrées, secrets, erreurs et abus doivent être traités comme sur toute autre API.
Talk Security To Me analyse les éléments publiquement visibles autour de votre domaine et de l’infrastructure qui l’accompagne.
app.example.comapi.example.comadmin.example.comstaging.example.comLe résultat n’est pas une sortie brute de scanner : les constats sont expliqués et transformés en plan d’action priorisé.
Sans accès au dashboard Supabase, au schéma ou au code source, Talk Security To Me ne peut valider toute la logique applicative. Ces contrôles doivent rester intégrés à votre développement sécurisé.
Le scan apporte une autre couche : la vision outside-in de votre surface d’attaque publique.
service_role dans le navigateurLovable peut générer l’interface et la logique applicative pendant que Supabase fournit Auth, base de données, API, fichiers et fonctions backend. Un fondateur non technique peut ainsi déployer une architecture complète sans voir toutes les décisions de sécurité prises en dessous.
Après le déploiement : vérifiez ce qui est public, passez en revue vos permissions Supabase et testez votre modèle d’autorisation.
Construisez avec Lovable, Cursor, Replit ou du code traditionnel. Passez en revue vos accès, déployez, observez votre surface externe, corrigez puis recommencez.
Créez votre application avec l’environnement de votre choix.
Contrôlez Auth, RLS, Storage et opérations privilégiées.
Déployez puis découvrez votre surface d’attaque publique.
Analysez les surprises, appliquez les changements et relancez le scan.
Votre infrastructure peut évoluer même si l’interface principale semble identique. Répétez le contrôle quand un nouveau composant rejoint la production.
Aucun identifiant Supabase requis. Aucun accès au code source. Aucune expertise sécurité nécessaire.
En lançant le scan, vous confirmez être autorisé à analyser ce domaine.