Supabase est-il conforme HIPAA ? Ce que la BAA vous laisse

Je suis Denys, ingénieur full-stack et IA, et la plupart des applications que je construis ou répare tournent sur Supabase. Quand une application de santé ou de bien-être demande si elle peut utiliser Supabase, la réponse honnête a deux parties : ce que Supabase signe, et ce que vous devez encore activer vous-même. Cet article les prend dans cet ordre, à partir des documents de Supabase, lus le 29 octobre 2026.

Supabase est-il conforme HIPAA ?

La plateforme hébergée l’est. Le guide HIPAA de Supabase indique qu’elle agit comme business associate pour les clients qui traitent des données de santé protégées (Protected Health Information, PHI), qu’elle a signé des BAA avec ses propres prestataires qui peuvent accéder à ces données, comme AWS, et que ses contrôles HIPAA sont audités chaque année sur la même période d’audit que SOC 2. Les projets HIPAA reçoivent aussi tous les contrôles SOC 2 du reste de la plateforme.

Deux limites figurent dans le même guide. Supabase auto-hébergé n’a pas ces contrôles d’office, et la conformité HIPAA y relève de vous et de votre auditeur. Et la BAA ne couvre que la part de Supabase : le guide liste vos responsabilités comme suivre les règles HIPAA de confidentialité, de sécurité et de notification des violations, signer la BAA et configurer vos projets HIPAA comme l’indique le Security Advisor.

De quoi avez-vous besoin avant de stocker des PHI ?

D’après la page des projets HIPAA et le modèle de responsabilité partagée :

1. L’offre Team ou supérieure. La BAA n’est pas disponible en dessous.
2. L’add-on HIPAA et une BAA signée. Vous demandez les deux à Supabase ; l’add-on est activé sur l’organisation.
3. High Compliance sur chaque projet. Avec l’add-on activé, un projet peut être marqué High Compliance dans les General Project Settings. Dès lors, Supabase exécute en continu des contrôles supplémentaires sur ce projet, et un réglage non conforme apparaît comme avertissement dans le Security Advisor.

Le Security Advisor avertit, il ne corrige pas. Le guide de Supabase est direct : la responsabilité d’appliquer les contrôles recommandés revient au client.

De quels réglages un projet HIPAA a-t-il besoin ?

Voici la liste complète du modèle de responsabilité partagée, avec l’endroit où se trouve chaque réglage et la mention de ce que le contrôle de sécurité Supabase gratuit peut voir. Le vérificateur lit un projet via la Management API de Supabase après votre connexion à Supabase : il voit des réglages, pas des contrats.

Votre obligation au titre de la BAA	Où elle se trouve	Vérificateur gratuit
Signer la BAA, offre Team ou supérieure	Contrat avec Supabase	Ne voit pas
Marquer les projets HIPAA, corriger les avertissements	General Project Settings, Security Advisor	En partie : affiche chaque alerte du Security Advisor qu’il reçoit
MFA sur chaque compte Supabase, imposée	Réglages de l’organisation	Ne voit pas
Point-in-time recovery (PITR)	Database → Backups, nécessite un petit add-on de calcul	En partie : passe avec les seules sauvegardes quotidiennes
Imposition de SSL	Database Settings → SSL Configuration	Le signale : “SSL not enforced on database connections”
Restrictions réseau	Database Settings → Network Restrictions	Le signale : “Database open to every IP address”
Journalisation des connexions Postgres activée	log_connections, désactivé par défaut sur les nouveaux projets	Ne voit pas
Chiffrement selon la HIPAA Security Rule	Supabase chiffre au repos et en transit	Ne voit pas ; le chiffrement au niveau de l’application est votre choix
Pas de PHI dans les buckets Storage publics	Storage → réglages du bucket	Signale chaque bucket public ; savoir s’il contient des PHI vous revient
Pas de transfert vers une organisation non HIPAA	Transfert de projet	Ne voit pas

Que manque le contrôle gratuit ?

Trois lacunes méritent d’être détaillées, car un résultat vert peut laisser croire à plus qu’il ne dit.

Les sauvegardes quotidiennes ne sont pas du PITR. La règle de sauvegarde du vérificateur passe quand le projet a du point-in-time recovery ou au moins une sauvegarde. Un projet payant avec des sauvegardes quotidiennes et sans PITR la passe. Les projets HIPAA ont besoin du PITR précisément, regardez donc Database → Backups vous-même ; le PITR exige au moins le petit add-on de calcul. Ce que garde chaque offre, et un test de restauration, est dans Supabase backups.

Deux réglages MFA différents. L’alerte “No multi-factor method enabled” du vérificateur concerne les utilisateurs de votre application : Supabase Auth leur propose-t-il un second facteur ? L’obligation HIPAA concerne les personnes qui peuvent ouvrir votre tableau de bord Supabase : MFA sur chaque compte de l’organisation, imposée comme exigence. Il vous faut les deux, et elles s’activent à des endroits différents.

Journalisation des connexions. Supabase met log_connections sur off dans les nouveaux projets, et les projets HIPAA devraient le garder activé pour la piste d’audit. Le vérificateur n’a aucune règle qui le lit. Dans l’éditeur SQL, show log_connections; y répond en une ligne, et le Security Advisor avertit à ce sujet sur un projet High Compliance.

Le vérificateur affiche chaque alerte que renvoie le Security Advisor, erreurs comme avertissements. Je ne l’ai pas exécuté sur un projet High Compliance, je ne peux donc pas confirmer que les avertissements HIPAA arrivent dans cette même liste. Lisez-les dans le tableau de bord dans tous les cas.

Ce que les réglages HIPAA ne couvrent pas

Aucune des dix obligations ne mentionne la Row Level Security. Un projet HIPAA où tous les réglages ci-dessus sont en place peut quand même servir une table de patients à quiconque possède la clé publique, si cette table a la RLS désactivée ou une politique qui autorise toutes les lignes. C’est la partie que le vérificateur lit en entier : droits (grants), politiques, fonctions qui contournent la RLS et colonnes d’apparence sensible lisibles par des visiteurs anonymes. La différence entre les deux clés est dans Supabase anon key vs service role key, et la façon dont je prouve chaque permission face à l’API est dans how to test Supabase RLS.

Il en va de même pour tout ce qui est hors de Supabase. Le modèle de responsabilité partagée met les services tiers à votre charge : fournisseurs SMTP et SMS, connexion OAuth, et toute API externe qu’appelle une Edge Function ou un trigger de base. Si l’un d’eux reçoit des PHI, il fait partie de votre périmètre HIPAA, pas de celui de Supabase : vérifiez donc que chaque fournisseur signe une BAA avant que les données n’y arrivent.

Comment vérifier votre projet ?

1. Dans le tableau de bord, confirmez que l’organisation a l’add-on HIPAA et que le projet est marqué High Compliance, puis ouvrez le Security Advisor et traitez chaque avertissement.
2. Ouvrez Database → Backups et confirmez que le PITR est activé, pas seulement les sauvegardes quotidiennes.
3. Exécutez show log_connections; dans l’éditeur SQL. Il doit renvoyer on.
4. Dans les réglages de l’organisation, confirmez que chaque membre a la MFA et que la MFA est obligatoire.
5. Lancez le contrôle de sécurité Supabase gratuit pour SSL, les restrictions réseau, les buckets publics et les règles d’accès ci-dessus. Ma note sur les buckets publics explique comment passer les fichiers à des URL signées.

Pour la question plus large de ce que la plateforme garantit et de ce qu’elle ne garantit pas, voir Supabase est-il sûr ?. Cet article n’est pas un conseil juridique ; votre responsable conformité ou votre auditeur décide de ce que votre BAA et votre programme HIPAA exigent.