ScanYourSite

Prüfen Sie, was Ihr Supabase-Projekt der Welt zeigt

Der anon key soll öffentlich sein. Der Schutz ist Row Level Security — und der eine Schlüssel, der sie umgeht, darf nie im Browser landen. Wir prüfen beides von außen, so wie ein Angreifer es tun würde, ohne Ihre Daten anzufassen.

Kostenlos, ohne Anmeldung. Die Basisprüfung stellt nur Anfragen, die auch ein normaler Browser stellt.

Vollständigen Beispielbericht ansehen

Was wir prüfen

Selbst prüfen in fünf Minuten

Alles, was wir von außen prüfen, können Sie in Ihrem eigenen Dashboard und Terminal prüfen. Tun Sie das nur bei Ihrem eigenen Projekt.

  1. Tabellen ohne Row Level Security auflisten

    Supabase-Dashboard → SQL Editor. Jede öffentliche Tabelle mit rowsecurity = false ist mit dem anon-Schlüssel lesbar, wenn die Standard-Grants bestehen. Der Security Advisor (Advisors → Security) zeigt dieselbe Liste.

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

  2. Als Fremder ausprobieren

    Nehmen Sie den anon-Schlüssel Ihrer Website — denselben, den jeder Besucher hat. Liefert das Zeilen, dann auch für jeden anderen.

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

  3. Sicherstellen, dass der geheime Schlüssel nie im Browser gelandet ist

    Öffnen Sie auf Ihrer Live-Website die DevTools und durchsuchen Sie alle geladenen Dateien (Cmd/Ctrl + Option/Alt + F) nach service_role und sb_secret_. Jeder Treffer heißt: Schlüssel in Project Settings → API rotieren, dann diesen Code in eine Edge Function verschieben.

  4. RLS aktivieren und eine Policy hinzufügen

    RLS ohne Policy blockiert alles — fügen Sie eine hinzu, die dazu passt, wie die Tabelle genutzt wird. Für eine Tabelle mit Benutzerprofilen:

    alter table public.profiles enable row level security;

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

Eine Lösung, die Ihre KI umsetzen kann

Der Prompt aus dem Bericht nennt die Tabellen und das genaue Problem und bittet Ihre KI, RLS mit Policies zu aktivieren, die dazu passen, wie die App jede Tabelle nutzt.

Behebe diese Probleme auf app.example.com.

1. Die Tabelle "profiles" liefert dem anon key 1.240 Zeilen.
   Aktiviere Row Level Security darauf und füge eine Policy hinzu, damit Nutzer nur ihre eigene Zeile per select lesen können (auth.uid() = id).

2. Die Tabelle "orders" liefert dem anon key 87 Zeilen.
   Aktiviere RLS; erlaube select nur dem Besitzer der Bestellung.

Wenn du fertig bist, prüfe erneut: https://scanyoursite.app/de?check=app.example.com

Neue Tabelle, neues Risiko

Jede Migration kann eine Tabelle ohne Policy hinzufügen. Mit Pro läuft die Tabellenprüfung bei jeder geplanten Prüfung, und von einer neu offenen Tabelle erfahren Sie noch am selben Tag.

Tarife ansehen

Fragen

Warum muss ich für die Tabellenprüfung meine Domain bestätigen?

Eine Datenbank abzufragen geht über das hinaus, was ein Browser auf einer Seite tut, deshalb machen wir das nur für den Inhaber. Die Bestätigung erfolgt per DNS-Eintrag, Datei oder Meta-Tag.

Speichern Sie meine Daten?

Nein. Wir zählen Zeilen mit einer HEAD-Anfrage und speichern nur die Zahl und den Tabellennamen.

Ist der anon key ein Leck?

Nein. Er ist absichtlich öffentlich. Wir führen ihn als Hinweis, nicht als Problem.

Für Vibe Coder

URL einfügen. Die Liste kommt in etwa einer Minute.

Zu jedem Fund steht, was er für Sie bedeutet und wie Sie ihn beheben — oder ein Prompt, den Ihr KI-Coding-Tool umsetzen kann.

Kostenlos, ohne Anmeldung. Die Basisprüfung stellt nur Anfragen, die auch ein normaler Browser stellt.