Guide

Contrôle de sécurité Supabase : RLS, clés exposées et stockage public

En bref

Un contrôle de sécurité Supabase vérifie que la sécurité par ligne (RLS) est activée et correcte sur chaque table, que la clé service-role n’atteint jamais le navigateur et qu’aucun espace de stockage n’est public par erreur. Hackaiz rejoue des requêtes anonymes pour prouver ce qui est réellement exposé, puis propose la règle corrigée.

Par l’équipe Hackaiz · HACKTUALIZ Inc. · Mis à jour le

Lancer mon premier scan

Les erreurs Supabase les plus fréquentes

  • RLS désactivée sur une table : n’importe qui avec la clé publique peut la lire.
  • Règles qui laissent chaque utilisateur connecté lire les lignes des autres.
  • Clé service-role publiée dans le dépôt ou le code du navigateur.
  • Rôles stockés dans la table des profils, permettant de s’auto-promouvoir.
  • Espaces de stockage publics contenant des fichiers privés.

Comment Hackaiz vérifie

Dans le code, Hackaiz relit les migrations SQL et les règles. Sur le projet en ligne, il envoie des requêtes anonymes en lecture seule et enregistre la réponse exacte comme preuve — un 401 signifie protégé, des lignes renvoyées signifient exposé. Avec votre accord, une connexion en lecture seule permet d’auditer rôles, tables et opérations dans une matrice.

Aucun test destructeur

Hackaiz n’écrit, ne supprime et ne modifie jamais de données. Les contrôles directs de base exigent l’accord du propriétaire et tournent en session lecture seule.