Supabase est-il sûr ? Ce qu’il couvre, ce qui vous revient

Je suis Denys, ingénieur full-stack et IA, et la plupart des applications que je construis ou répare tournent sur Supabase. Les clients demandent « Supabase est-il sûr ? » en pensant « mes données sont-elles en sécurité ? ». Ce sont deux questions aux réponses différentes, je les prends donc l’une après l’autre.

Supabase est-il sûr ?

La plateforme est auditée par des tiers. D’après la page sécurité et la documentation sécurité de Supabase, lues le 23 octobre 2026 :

Contrôle	Ce que Supabase indique
SOC 2 Type 2	Audité chaque année ; le rapport est disponible pour les clients Team et Enterprise
ISO 27001	Certifié ; le certificat est disponible pour les clients Team et Enterprise
HIPAA	Pris en charge avec un Business Associate Agreement signé et l’add-on HIPAA, à partir de l’offre Team
Chiffrement	AES-256 au repos, TLS en transit ; les jetons d’accès et les clés sont aussi chiffrés au niveau de l’application
Sauvegardes	Quotidiennes pour les projets payants ; Point in Time Recovery en add-on à partir de l’offre Pro
Résidence des données	La base, Auth et Storage restent dans la région AWS que vous choisissez

Rien de tout cela ne protège une table que vous avez laissée ouverte. Le guide SOC 2 le dit sans détour : la conformité de Supabase ne s’étend pas à ce qui échappe à son contrôle.

Quelle est votre part ?

Le modèle de responsabilité partagée de Supabase liste ce qui vous revient toujours : votre compte, la gestion des accès à la base et à ses tables, vos données, et l’application des contrôles de sécurité, y compris les avertissements que lève le Security Advisor. En pratique, cela donne quatre couches de réglages :

1. Qui peut toucher une table. Les droits (grants) décident si anon et authenticated atteignent une table. Les politiques RLS décident quelles lignes.
2. Quelle clé va où. La publishable key est publique par conception, la secret key contourne la RLS. Je les ai comparées dans Supabase anon key vs service role key.
3. Réglages d’authentification. Confirmation par e-mail, leaked password protection (offre Pro et au-dessus), longueur minimale du mot de passe, MFA, URL de redirection, CAPTCHA.
4. Tout ce qui entoure la base. Buckets de stockage et leurs politiques, fonctions SECURITY DEFINER, Edge Functions qui utilisent la secret key, et schémas que la Data API expose.

Combien un seul réglage change-t-il ?

J’ai exécuté la même requête contre une table de trois fausses commandes sur un stack Supabase local (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), avec la publishable key, comme le ferait un navigateur :

Réglage de la table	Ce que la clé publique a obtenu
RLS désactivée	Les 3 lignes, et une insertion a renvoyé 201 Created
RLS activée, aucune politique	[]
RLS activée, politique using (true)	Les 3 lignes
Aucun droit pour anon	42501 permission denied

Même plateforme, même chiffrement, mêmes certifications. La différence tient en une ligne de SQL. C’est pourquoi une « plateforme sûre » et une application qui fuit ne sont pas contradictoires : la CVE-2025-48757 a trouvé 170 des 1 645 applications vitrines de Lovable servant des données à la clé publique, toutes sur la même plateforme auditée.

Supabase devient-il plus sûr par défaut ?

Oui, par étapes. Le changelog du 28 avril 2026 de Supabase liste une option RLS activée par défaut, un badge d’exposition de la Data API, des droits fins par table et une restriction de l’énumération des schémas. La plus importante arrive le 30 octobre 2026 : les nouvelles tables des projets existants ne reçoivent plus automatiquement de droits pour la Data API, si bien qu’une table oubliée renvoie 42501 au lieu de ses lignes. Les tables existantes gardent leurs droits, cela ne corrige donc rien de ce qui est déjà ouvert. Les anciennes clés anon et service_role sont aussi abandonnées d’ici fin 2026 au profit des publishable et secret keys ; la nouvelle secret key refuse les requêtes venant d’un navigateur.

Ce que le basculement casse d’autre et comment vérifier le projet avant : Supabase, changement des grants du 30 octobre : que vérifier.

Comment vérifier votre propre projet ?

Commencez par le Security Advisor de Supabase et corrigez chaque avertissement. Vérifiez ensuite ce qu’il ne couvre pas :

• Lancez l’audit de sécurité Supabase gratuit. Il se connecte en lecture seule et note le projet sur 46 règles associées à l’OWASP Top 10:2025 : RLS, politiques, vues, fonctions, droits, stockage et réglages d’authentification, avec le SQL de correction pour chaque constat.
• Testez avec deux utilisateurs dans deux entreprises. Aucun scanner ne sait à qui appartiennent les lignes ; le test est dans ma checklist de sécurité d’une application Lovable.
• Si votre application a des rôles et un écran de permissions, prouvez que chaque case de permission fait ce qu’elle dit, comme dans comment tester Supabase RLS.

Donc : Supabase est un endroit sûr pour garder des données, et il vous donne les outils pour les garder privées. Qu’elles le restent se décide dans votre schéma et vos réglages.