La checklist de sécurité Supabase

Supabase te donne une API automatique sur ta base (une Postgres, gratuite pour démarrer) : dès que tu crées une table, elle est requêtable depuis Internet avec la clé publique du projet. Ce qui décide qui lit quoi, ce n'est pas la clé : c'est la Row Level Security (RLS), des règles posées sur chaque table. Une table sans RLS, dans un schéma exposé, est lisible et modifiable par n'importe quel visiteur.

• Active la RLS sur chaque table du schéma public : alter table public.ma_table enable row level security;
• Passe le Security Advisor du dashboard (ou supabase db advisors) et règle chaque ERREUR. Il liste les tables « unrestricted », les policies posées sur une table dont la RLS est désactivée (elles ne s'appliquent pas), et les colonnes sensibles exposées.
• RLS activée mais aucune policy = tout est refusé. C'est le bon défaut (« deny by default ») : tu ouvres ensuite, ligne par ligne, avec des policies.
• Une policy par opération (select, insert, update, delete), filtrée par (select auth.uid()) ; jamais de using (true) sur des données privées.
• Attention aux vues : par défaut une vue ignore la RLS des tables qu'elle lit. Sur Postgres 15+, crée-la en security_invoker = true, sinon ne l'expose pas.

Voici le trou le plus courant, et le plus discret. Tu écris une policy saine : « un utilisateur peut modifier sa ligne de profil ».

create policy "je modifie mon profil"
  on public.profiles for update
  using  ( (select auth.uid()) = id )
  with check ( (select auth.uid()) = id );

Le problème : cette règle dit quelle ligne, pas quelles colonnes. Depuis la console du navigateur, avec la clé publique, l'utilisateur envoie :

supabase.from('profiles')
  .update({ is_admin: true })
  .eq('id', monPropreId)

La policy est satisfaite — c'est bien sa ligne — et il devient admin. Cacher le champ dans ton interface ne change rien : l'API répond directement. Quatre façons de fermer le trou :

Supabase te donne deux clés (renommées récemment, les anciens noms cohabitent encore) :

• Cherche la clé secrète là où elle n'a rien à faire : dans le bundle (grep sb_secret_ sur ton build), dans les .env commités, et dans l'historique git (git log -p -S sb_secret_).
• Si elle a fuité une seule fois, considère-la compromise : corrige la cause, puis fais tourner la clé (crée la neuve, déploie, supprime l'ancienne). La retirer du code ne suffit pas : les anciens builds et les caches la gardent.
• Ne compte pas sur le blocage navigateur. Supabase refuse une clé secrète envoyée depuis un navigateur (erreur 401), mais c'est un garde-fou : une clé fuitée reste utilisable depuis n'importe quel autre outil.

Si tu vends du contenu — des vidéos, des PDF — le piège est simple : dès que le navigateur affiche le fichier, il en a reçu l'URL. Les outils de développement, l'onglet réseau ou le code source la récupèrent. Un « paywall » qui ne fait que masquer le lecteur ne protège rien.

• Les fichiers payants vont dans un bucket privé. Les buckets sont privés par défaut ; dans un bucket public, la lecture est ouverte à quiconque a l'URL.
• On les sert par URL signée (createSignedUrl), générée côté serveur, après avoir vérifié que la personne a payé, et qui expire vite (quelques minutes).
• Ne stocke jamais l'URL publique du fichier en base : une table qui liste tes vidéos avec leur lien, lisible par la clé publique, fuite tout le catalogue d'un coup.
• Pose des policies RLS sur storage.objects, en liant le chemin du fichier au droit de la personne (pas un simple « connecté »), et vérifie qu'un bucket public n'a pas de policy qui laisse lister son contenu.

Une fonction Postgres en SECURITY DEFINER s'exécute avec les droits de son créateur — souvent un rôle qui contourne la RLS. Comme toute fonction est, par défaut, exécutable par n'importe quel rôle (anon compris) via /rest/v1/rpc, elle peut renvoyer des lignes que l'appelant ne devrait pas voir.

• Préfère SECURITY INVOKER (le défaut) ; chaque DEFINER doit être justifié.
• Toute fonction DEFINER fixe set search_path = '' et qualifie les noms (public.ma_table) — sinon, détournement possible (lint 0011).
• Révoque EXECUTE sur les fonctions qui n'ont pas à être publiques : revoke execute on function … from public, anon;
• Une fonction qui renvoie des données par utilisateur revérifie la propriété dans son corps (where user_id = (select auth.uid())) : le droit d'exécuter ne limite pas les lignes rendues.

• Confirmation d'email activée en production (sur un projet auto-hébergé, elle est désactivée par défaut).
• Site URL = ton URL de production, et une liste blanche de Redirect URLs en chemins exacts — pas de joker ** large, réservé aux previews.
• Mot de passe : longueur minimale raisonnable, et protection contre les mots de passe déjà fuités (HaveIBeenPwned, à partir du plan Pro).
• Limites de débit et CAPTCHA sur inscription, connexion et réinitialisation ; SMTP sur ton propre domaine.
• Ne publie pas les emails : le schéma auth n'est pas exposé à l'API ; passe par une table profiles sous RLS, et n'y mets que du public.
• Le JWT est signé mais lisible : n'y mets jamais de secret. Côté serveur, vérifie le jeton auprès de Supabase, ne te fie pas à un décodage local.
• Connexions anonymes activées ? Un utilisateur anonyme porte le rôle authenticated : relis toutes tes policies to authenticated.

Supabase se branche presque toujours à une appli — souvent Next.js, hébergée sur Vercel dans ma stack. Deux pièges s'ajoutent à la base de données.

• Tout ce qui est préfixé NEXT_PUBLIC_ est public : Next.js l'écrit en dur dans le JavaScript du navigateur au build. NEXT_PUBLIC_SUPABASE_URL et la clé publishable, d'accord ; une clé secret préfixée ainsi, catastrophe. (Même piège avec le bloc env: {} de next.config.js.)
• Une page compilée en statique est publique, données comprises. Ce qu'un composant serveur lit au build est figé dans le HTML et servi à tous ; avec output: 'export', il n'y a aucun serveur, donc rien n'est protégeable par ce biais. Ne lis jamais de donnée privée dans une page destinée à être statique.
• Le contrôle d'accès se fait côté serveur, au plus près de la donnée. Une route d'API, une Server Action : chacune revérifie qui appelle et si la ressource lui appartient (sinon, on change l'id dans l'URL et on lit la ressource d'un autre). Cacher un bouton ne protège pas la donnée derrière.
• Les source maps de prod sont désactivées (défaut), /public ne contient aucun fichier réservé, et Next.js est à jour (la faille de contournement du middleware, CVE-2025-29927, concernait les apps auto-hébergées).

Une IA de code est très douée pour te dire que c'est sécurisé, même quand ça ne l'est pas. La parade : lui demander l'inverse, de chercher ce qui est exposé, sur ta propre application. C'est un auto-audit, la même idée que de relire son code avant de livrer. Colle ces prompts dans ton assistant, avec ton dépôt ouvert.

D'abord le cadre : on ne teste que sa propre app, ou une app pour laquelle on a une autorisation écrite. Jamais le site de quelqu'un d'autre. Tout ce qui écrit se fait sur un environnement de test, avec des comptes que tu as créés.

Et un dernier, en relecteur sceptique : « Voici les rapports précédents de mon app. Dédoublonne, classe par gravité, et pour chaque point critique dis-moi comment je le reproduis moi-même. Signale surtout ce que tu n'as PAS pu vérifier, plutôt que de conclure que tout est bon. » La liste des angles morts compte autant que les failles trouvées.