ScanYourSite

Vérifiez ce que votre projet Supabase montre au monde

La clé anon est censée être publique. La protection, c'est Row Level Security — et la seule clé qui la contourne ne doit jamais atteindre le navigateur. Nous vérifions les deux de l'extérieur, comme le ferait un attaquant, sans toucher à vos données.

Gratuit, sans inscription. L'analyse de base n'envoie que les requêtes qu'un navigateur ordinaire enverrait.

Voir un rapport complet d'exemple

Ce que nous vérifions

Vérifiez vous-même en cinq minutes

Tout ce que nous vérifions de l'extérieur, vous pouvez le vérifier depuis votre propre tableau de bord et votre terminal. Faites-le uniquement sur votre propre projet.

  1. Listez les tables sans Row Level Security

    Tableau de bord Supabase → SQL Editor. Toute table public avec rowsecurity = false est lisible avec la clé anon si les droits par défaut sont en place. Le Security Advisor (Advisors → Security) affiche la même liste.

    select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

  2. Essayez comme un inconnu

    Utilisez la clé anon de votre site — la même que celle de chaque visiteur. Si cette requête renvoie des lignes, elle en renvoie aussi pour n'importe qui.

    curl 'https://<project>.supabase.co/rest/v1/<table>?select=*&limit=1' \
  -H "apikey: <anon key>" \
  -H "Authorization: Bearer <anon key>"

  3. Assurez-vous que la clé secrète n'a jamais atteint le navigateur

    Sur votre site en ligne, ouvrez DevTools et cherchez service_role et sb_secret_ dans tous les fichiers chargés (Cmd/Ctrl + Option/Alt + F). Le moindre résultat signifie : renouvelez la clé dans Project Settings → API, puis déplacez ce code dans une Edge Function.

  4. Activez RLS et ajoutez une politique

    Activer RLS sans politique bloque tout — ajoutez-en une qui correspond à l'usage de la table. Pour une table de profils utilisateurs :

    alter table public.profiles enable row level security;

create policy "read own profile"
on public.profiles for select
using (auth.uid() = id);

Un correctif que votre IA peut appliquer

Le prompt du rapport nomme les tables et le problème exact, et demande à votre IA d'activer RLS avec des politiques adaptées à l'usage que l'app fait de chaque table.

Corrige ces problèmes sur app.example.com.

1. La table "profiles" renvoie 1 240 lignes à la clé anon.
   Active Row Level Security dessus et ajoute une politique pour que chaque utilisateur ne puisse sélectionner que sa propre ligne (auth.uid() = id).

2. La table "orders" renvoie 87 lignes à la clé anon.
   Active RLS ; n'autorise le select qu'au propriétaire de la commande.

Une fois terminé, revérifie : https://scanyoursite.app/fr?check=app.example.com

Une nouvelle table, un nouveau risque

Chaque migration peut ajouter une table sans politique. Avec Pro, la vérification des tables tourne à chaque analyse planifiée, et vous apprenez le jour même qu'une table vient de s'ouvrir.

Voir les offres

Questions

Pourquoi confirmer mon domaine pour la vérification des tables ?

Interroger une base de données va au-delà de ce que fait un navigateur sur une page : nous ne le faisons donc que pour le propriétaire. La confirmation se fait par un enregistrement DNS, un fichier ou une balise meta.

Stockez-vous mes données ?

Non. Nous comptons les lignes avec une requête HEAD et ne gardons que le nombre et le nom de la table.

La clé anon est-elle une fuite ?

Non. Elle est publique par conception. Nous la signalons comme une information, pas comme un problème.

Pour les vibe coders

Collez votre URL. Recevez la liste en une minute environ.

Chaque constat explique ce qu'il signifie pour vous et comment le corriger — ou vous donne un prompt que votre outil de code IA peut appliquer.

Gratuit, sans inscription. L'analyse de base n'envoie que les requêtes qu'un navigateur ordinaire enverrait.