Supabase est-il sûr ?
Analyse de sécurité des apps créées avec Supabase. Alternative open source à Firebase avec PostgreSQL, authentification, stockage et abonnements en temps réel.
Supabase est-il sûr ? La réponse courte
Supabase est une plateforme sûre : elle repose sur PostgreSQL, utilise la Row Level Security (RLS) de Postgres pour les autorisations, et son infrastructure est gérée par une équipe dédiée. Mais Supabase est conçu pour que votre front-end parle directement à la base via une API générée automatiquement. Ce modèle n'est sûr que si vos politiques RLS sont correctes.
C'est la grande différence avec un backend classique : la clé publique (anon ou publishable) présente dans votre JavaScript est faite pour être publique. Ce qui protège vos données, ce n'est pas cette clé, ce sont les politiques définies sur chaque table. Une table sans RLS, ou avec une politique qui autorise tout le monde à lire, est lisible par n'importe qui ouvrant l'onglet réseau de votre app. C'est le problème critique le plus fréquent dans les apps Supabase développées en vibe coding.
Nous avons scanné le site de Supabase
5 oct. 2026Ce scan porte sur https://supabase.com. Votre app créée avec Supabase peut obtenir des résultats différents.
Scannez votre app Supabase maintenant
Saisissez votre URL et obtenez un rapport de sécurité complet en 30 secondes. Gratuit, sans inscription.
Scanner mon app SupabaseLes erreurs de configuration Supabase fréquentes dans les apps créées avec l'IA
RLS désactivée sur des tables exposées par l'API
Les tables créées en SQL brut ou par migration n'ont pas de Row Level Security tant que vous ne l'activez pas. Sans RLS, la clé publique donne un accès en lecture et en écriture à toute la table via l'API REST.
Des politiques qui autorisent tout
Activer la RLS puis ajouter une politique using (true) pour chaque opération revient à ne pas avoir de RLS. Les politiques doivent comparer le propriétaire de la ligne à auth.uid(), séparément pour select, insert, update et delete.
La clé service_role dans le front-end
La clé service_role (comme les nouvelles clés secrètes) contourne totalement la RLS. Elle ne doit jamais apparaître dans une variable NEXT_PUBLIC_ ou VITE_ ni dans du code client. Utilisez-la uniquement dans du code serveur ou des Edge Functions.
Des buckets publics pour des fichiers privés
Les fichiers d'un bucket public peuvent être téléchargés par toute personne qui connaît l'URL. Factures, pièces d'identité ou fichiers envoyés par les utilisateurs doivent aller dans un bucket privé, servis par URL signée et protégés par des politiques sur storage.objects.
Des vues et fonctions qui contournent la RLS
Par défaut, une vue s'exécute avec les droits de son créateur et peut donc exposer des lignes que la RLS masquerait ; sur les versions récentes de Postgres, créez vos vues avec security_invoker = true. Les fonctions déclarées security definer et appelables en RPC méritent la même vigilance.
Checklist de sécurité Supabase
- Activez la RLS sur chaque table des schémas exposés et lancez le Security Advisor du tableau de bord Supabase.
- Écrivez une politique par opération, filtrée avec
auth.uid(), et testez-les connecté avec deux utilisateurs différents. - Gardez la clé
service_roleou la clé secrète côté serveur uniquement ; faites-en la rotation si elle a déjà été envoyée au navigateur. - Rendez les buckets privés par défaut et utilisez des URL signées pour les fichiers sensibles.
- Passez en revue les vues, les fonctions
security defineret les endpoints RPC.
alter table public.profiles enable row level security;
create policy "Chaque utilisateur lit son propre profil"
on public.profiles for select
to authenticated
using ((select auth.uid()) = id);Pour aller plus loin : Comment sécuriser votre app Supabase en 10 minutes
Failles de sécurité fréquentes dans les apps Supabase
Clés API exposées
Les outils de code IA intègrent souvent les clés API directement dans le JavaScript côté client. Si vous utilisez Supabase, vérifiez qu'aucune clé secrète ne se trouve dans votre bundle front-end.
En-têtes de sécurité manquants
Des en-têtes comme Content-Security-Policy, Strict-Transport-Security et X-Frame-Options protègent contre les attaques XSS, le clickjacking et les attaques par rétrogradation (downgrade).
Dépendances vulnérables
Les paquets npm obsolètes présentant des CVE connues sont fréquents dans le code généré par IA. Des audits réguliers permettent de les repérer avant les attaquants.
Faiblesses d'authentification
Endpoints d'inscription ouverts, absence de limitation de débit (rate limiting) et jetons d'authentification exposés sont des problèmes fréquents dans les apps développées en vibe coding.
Ce que ScanVibe vérifie
Questions fréquentes
Supabase est-il sûr à utiliser ?
Supabase est en soi une plateforme reconnue, mais les apps créées avec Supabase présentent souvent des erreurs de configuration de sécurité : clés API exposées, en-têtes de sécurité manquants et dépendances vulnérables. ScanVibe analyse votre app pour détecter ces problèmes.
Quelles failles de sécurité trouve-t-on souvent dans les apps Supabase ?
Les problèmes les plus fréquents que nous détectons dans les apps Supabase sont : des clés API exposées dans le JavaScript côté client, des en-têtes de sécurité manquants (CSP, HSTS), des dépendances obsolètes présentant des vulnérabilités connues et des endpoints d'authentification mal configurés.
Comment vérifier si mon app Supabase est sécurisée ?
Saisissez l'URL de votre app dans le scanner ScanVibe. Nous vérifions les secrets exposés, les en-têtes de sécurité, les bibliothèques vulnérables, les fichiers exposés et les erreurs de configuration propres à chaque plateforme, le tout en 30 secondes environ.
ScanVibe analyse-t-il spécifiquement Supabase ?
Oui. ScanVibe détecte Supabase dans votre stack et exécute des contrôles de sécurité propres à cette plateforme, en plus de notre analyse standard en 8 catégories.
Est-il sûr d'exposer la clé anon de Supabase ?
Oui, la clé anon (ou publishable) est conçue pour être publique et se trouve dans tous les front-ends Supabase. Elle n'est sûre que si la Row Level Security est activée, avec des politiques correctes, sur chaque table exposée. La clé service_role et les clés secrètes, elles, contournent la RLS et ne doivent jamais quitter votre serveur.
Comment activer la Row Level Security dans Supabase ?
Exécutez alter table <table> enable row level security pour chaque table (ou utilisez l'interrupteur de l'éditeur de tables), puis créez des politiques pour select, insert, update et delete qui comparent le propriétaire de la ligne à auth.uid(). Avec la RLS activée et aucune politique, la table n'est plus du tout accessible via l'API publique : c'est un réglage par défaut sûr.
Autres bases de données à vérifier
Plateforme de développement d'applications de Google avec Firestore, Realtime Database, authentification, hébergement et Cloud Functions.
PlanetScale est-il sûr ?Base de données MySQL serverless avec branches, modifications de schéma non bloquantes et Vitess.
Neon est-il sûr ?PostgreSQL serverless avec branches, mise à l'échelle automatique et une offre gratuite généreuse pour les développeurs.
Convex est-il sûr ?Backend-as-a-service réactif avec base de données en temps réel, fonctions serveur et stockage de fichiers.
Ne devinez pas : scannez.
Détectez les failles de sécurité de votre app Supabase avant les attaquants.
Scanner mon app