Supabase security checker : les cinq vérifications à faire soi-même

Vous avez cherché un Supabase security checker et vous en avez trouvé neuf. L'un veut votre dépôt. L'autre veut une extension de navigateur. Un troisième veut un accès en lecture à tout votre compte Supabase, ce qui ressemble assez à la chose qui vous inquiétait pour vous faire hésiter.

Voici ce qu'aucune de ces pages produit ne dit à voix haute. Il y a cinq vérifications, et vous pouvez toutes les faire vous-même, sans compte, sans installation, et sans aucun des identifiants qu'il serait dangereux de confier. Dix minutes dans un terminal couvrent le même terrain que les outils.

Les cinq ci-dessous sont celles que notre propre scanner lance sur un projet Supabase, écrites sous forme de commandes. Si vous avez construit avec Lovable, Bolt, v0, Cursor, Replit, Windsurf ou Base44 et que votre app stocke quoi que ce soit, la base derrière est très probablement Supabase, et voici les questions qu'un inconnu lui poserait.

Que vérifie vraiment un Supabase security checker ?

Votre app publiée. Les réglages à l'intérieur de votre projet sont le travail d'un autre outil, et Supabase livre déjà cet outil.

Le Security Advisor de votre tableau de bord lit le catalogue de votre projet : quelles tables ont la Row Level Security désactivée, quelles fonctions ont un search path trop large, quelles extensions vivent dans le schéma public. Il lit ce que vous avez configuré.

Un checker lit ce que votre app tend à un inconnu. Le bundle JavaScript que vos visiteurs téléchargent, la réponse qu'une table donne à une requête sans session, le contenu d'un bucket de stockage, les en-têtes de vos pages. De votre configuration il ne voit rien, et il n'en a pas besoin, parce qu'il regarde la conséquence.

Les deux moitiés se séparent plus souvent que les noms ne le laissent croire. Une table peut passer l'Advisor avec l'interrupteur activé et une policy écrite, et livrer quand même ses lignes à tout le monde, parce que la policy qui a été écrite laisse entrer tout le monde. Cela mérite sa propre lecture si c'est nouveau pour vous : l'interrupteur n'est pas la protection.

Vérification 1 : quelle clé Supabase votre app livre-t-elle ?

Ouvrez votre app dans un navigateur, appuyez sur F12, et regardez une seule requête.

Allez dans l'onglet Réseau, rechargez la page, et tapez supabase dans le filtre. Votre app fera au moins une requête vers une adresse finissant par .supabase.co. Cliquez dessus. Les deux choses dont vous avez besoin pour la suite de cet article s'y trouvent :

• L'adresse de la requête commence par l'URL de votre projet, quelque chose comme https://abcdefghij.supabase.co. Les vérifications 2 et 3 la visent.
• L'en-tête de requête apikey porte la clé que votre app tend à chaque visiteur.

Copiez les deux quelque part, puis lisez la clé elle-même. Une clé commençant par sb_publishable_ a sa place dans votre app et il n'y a rien à réparer. Une clé commençant par sb_secret_ n'y a jamais sa place, et la trouver met fin à la liste tout de suite : faites-la tourner aujourd'hui, avant tout le reste de cette page. Les anciens projets portent une paire sans préfixe lisible, anon et service_role, et les distinguer veut dire lire le rôle à l'intérieur de la clé.

Ce dernier cas est rare. Sur les 30 998 apps en ligne que nous avons scannées en août 2026, une clé secrète Supabase dans le navigateur est apparue trois fois.

Tant que l'onglet Réseau est ouvert, notez les noms de table visibles dans ces adresses de requête. La vérification suivante en a besoin.

Vérification 2 : vos tables répondent-elles à un inconnu ?

Demandez à la base combien de lignes elle donnerait à quelqu'un sans session, et lisez le nombre dans la réponse.

curl -s -i \
  -H "apikey: VOTRE_CLE_PUBLIABLE" \
  -H "Prefer: count=exact" \
  -H "Range: 0-0" \
  "https://VOTRE_PROJET.supabase.co/rest/v1/profiles?select=count" \
  | grep -i content-range

Mettez la clé et l'adresse du projet de la vérification 1, et votre propre nom de table à la place de profiles. curl est déjà installé sur macOS, sur Linux et sur Windows récent, il n'y a donc rien à récupérer avant.

Cette requête ne récupère aucune ligne. select=count demande un décompte, Range: 0-0 ne demande aucune des lignes elles-mêmes, et toute la réponse arrive dans un seul en-tête. C'est la requête que fait notre scanner, et c'est pour cela qu'il peut tourner sur l'app en ligne de quelqu'un sans toucher à ses données.

Quatre choses peuvent revenir, et l'une d'elles est un constat :

Le refus est la ligne sur laquelle il faut être prudent. Un 401 dit que la requête s'est arrêtée avant d'atteindre la table, ce qui ne vous apprend rien sur la protection de cette table, et c'est la plus facile des quatre à arrondir en coche verte.

Lancez la commande pour chaque table nommée par votre app à la vérification 1, puis pour les ordinaires qu'une app a en général : users, profiles, customers, orders, messages, invoices. Ces six-là contiennent les données d'autres personnes.

C'est la vérification qui trouve le plus. Sur les 3 680 apps Supabase où nous avons pu la mener à bout, 2 096 avaient au moins une table qui répondait à une requête sans session, et dans 394 d'entre elles la table ouverte portait un nom de personnes. La mesure complète et ce dont ce chiffre est une part fait l'objet d'un article séparé.

Vérification 3 : un bucket de stockage liste-t-il ses propres fichiers ?

Demandez à un bucket son contenu et regardez si quelque chose revient.

curl -s -X POST \
  -H "apikey: VOTRE_CLE_PUBLIABLE" \
  -H "Content-Type: application/json" \
  -d '{"prefix":"","limit":1}' \
  "https://VOTRE_PROJET.supabase.co/storage/v1/object/list/avatars"

Envoyez le body. Un POST vers cette adresse sans rien dedans répond "Body cannot be empty" pour tous les buckets de tous les projets, quelle que soit leur configuration. Nous le savons parce que notre propre vérification de buckets est partie comme ça et a passé des mois à annoncer joyeusement que rien n'était listable.

Deux formes de réponse :

• [] veut dire que le bucket est fermé, ou qu'aucun bucket ne porte ce nom. De l'extérieur vous ne pouvez pas savoir lequel, donc une liste vide ne prouve rien.
• Un tableau contenant un fichier veut dire qu'un inconnu peut demander à votre projet un répertoire de ce bucket et l'obtenir.

Essayez les noms de bucket qu'utilise votre app, puis les plus courants : avatars, public, uploads, files, images, documents.

Listable et public sont deux réglages différents rangés à deux endroits différents, et la différence décide de l'importance d'un bucket public. Le listing est celui qu'il faut fermer, parce qu'il épargne à un inconnu le travail de deviner un nom de fichier. Sur les 27 269 apps où nous avons pu poser la question, 792 ont répondu par une liste.

Vérification 4 : votre code source est-il publié à côté de votre app ?

Lisez la dernière ligne de votre bundle JavaScript.

De retour dans l'onglet Réseau de la vérification 1, trouvez le plus gros fichier .js chargé par votre app et copiez son adresse. Puis :

curl -s "https://votre-app.example/assets/index-abc123.js" | tail -c 120

Une dernière ligne indiquant //# sourceMappingURL=index-abc123.js.map veut dire que votre build a écrit une source map et a dit aux navigateurs où elle se trouve. Savoir s'il l'a vraiment publiée demande une requête de plus :

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://votre-app.example/assets/index-abc123.js.map"

200 veut dire que n'importe qui peut la télécharger. Une source map retransforme le JavaScript compressé en vos fichiers d'origine, avec votre arborescence, vos commentaires et votre logique intacts. Ce qu'elle expose, c'est votre code, et toute clé qu'elle révèle se trouvait déjà à côté dans le bundle, ce qui était l'objet de la vérification 1. 3 885 des 30 987 apps que nous avons pu examiner publient la leur, et chez certains builders c'est un réglage par défaut de la plateforme et non une décision de quelqu'un : ce que montre une source map publiée.

Vérification 5 : ce que votre hébergeur envoie avec chaque page

Une requête vers l'adresse de votre app, et on lit ce qui est revenu avec elle.

curl -s -i "https://votre-app.example" | grep -i -E \
  "content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy"

Cinq en-têtes, et ceux qui ne s'affichent pas sont ceux qui vous manquent. Ils disent au navigateur de refuser la page si elle est chargée dans le site de quelqu'un d'autre, d'exiger une connexion chiffrée la prochaine fois, et d'arrêter de deviner le type de fichier qu'il vient de recevoir.

Presque toutes les apps échouent ici et presque personne ne peut agir dessus. Il en manquait au moins un à 30 756 des 30 981 apps que nous avons pu examiner, parce que c'est la plateforme d'hébergement qui les envoie et qu'un propriétaire sur un sous-domaine de builder n'a nulle part où les changer. Nous le comptons et le plafonnons à moyen : ce que les en-têtes manquants prédisent et ne prédisent pas.

Comment lire ce que vous avez trouvé

Par gravité, et ce n'est pas l'ordre dans lequel vous les avez lancées.

Une clé secrète dans le bundle passe en premier. Elle saute toutes les règles que vous avez écrites sur toutes les tables, alors faites-la tourner avant de regarder quoi que ce soit d'autre ici.

Une table pleine de personnes qui répond à la vérification 2 vient ensuite.users, profiles, orders et messages contiennent les données d'autres gens, et elles sont accessibles à cet instant. Une table products qui répond pareil peut être tout à fait correcte, et vous êtes la seule personne capable de les distinguer.

Puis un bucket listable, puis les maps et les en-têtes, qui sont en général les réglages par défaut de votre plateforme et non quelque chose que vous avez choisi.

Une chose à retenir des cinq. Une vérification restée sans réponse n'a pas réussi. Un 401, une requête qui expire, une table dont vous avez mal deviné le nom : chacune de ces situations est une question encore ouverte. Notre scanner écrit « Vérification impossible » sur ces lignes et laisse la note tranquille, et le faire à la main veut dire tenir cette liste vous-même.

Tout ceci décrit aussi l'app qui était en ligne au moment où vous avez posé la question. La Row Level Security se désactive pour qu'une page s'affiche, un bucket s'ouvre pour un envoi, une clé se colle pour qu'une fonctionnalité sorte ce soir.

Que faire cette semaine

Notre scanner de sécurité gratuit lance ces cinq vérifications et quatre autres sur n'importe quelle URL en ligne en une vingtaine de secondes, sans compte et sans identifiants à confier. Il lit, n'écrit jamais, et là où il n'obtient pas de réponse il l'écrit sur la ligne.

Les cinq, vous pouvez les faire vous-même aujourd'hui. Ce qu'aucun passage unique ne peut vous dire, c'est si les réponses seront les mêmes le mois prochain, et c'est pour cela que nous avons construit Reeve Care : il relance ces vérifications selon un calendrier, vous écrit quand une réponse se dégrade, et conserve des sauvegardes vérifiées de votre base Supabase, ainsi que les fichiers envoyés par vos utilisateurs dès que vous connectez un accès au stockage. Ce qu'il surveille et ce qu'il coûte.

Si un terminal n'est pas là où vous voulez être, le guide en langage clair pour les apps Supabase explique à quoi sert chacun de ces réglages et où le trouver dans le tableau de bord.