Hinweis: Sie können diese Seite lokal speichern (Strg+S) und von Ihrem Computer aus verwenden. Der Scan läuft vollständig in Ihrem Browser - es ist kein Server beteiligt. Die Seite funktioniert auch offline gespeichert als .html Datei.

Supabase Security Check

Ist Ihre Supabase-Datenbank öffentlich zugänglich? Finden Sie es in 30 Sekunden heraus.

Hintergrund (Stand April 2026)

Das Kernproblem. Supabase aktiviert Row Level Security (RLS) nur für Tabellen, die über den Dashboard Table Editor angelegt werden, standardmäßig. Tabellen, die über den SQL Editor, CLI-Migrations, ORMs (Prisma, Drizzle, TypeORM), psql-Batches, pg_dump/restore oder KI-Coding-Tools (Lovable, Bolt, v0, Cursor, Replit Agent) erstellt werden, starten ohne RLS. Der anon-Rolle ist per Default SELECT auf das public-Schema erteilt – der im Frontend eingebettete API-Key erlaubt dann uneingeschränkten Lesezugriff auf alle Tabelleninhalte. Die Dashboard-only-Voreinstellung ist seit 2022 dokumentiert (Issue #4991).

Was Supabase 2025/2026 geändert hat. Im 2025 Security Retrospective wurden mehrere Maßnahmen angekündigt und teilweise umgesetzt:
  • Ein optionaler Event-Trigger, der RLS bei Projektanlage automatisch aktiviert (PR #42021) – Opt-in-Checkbox bei Projektanlage, nicht retroaktiv, kein Plattform-Default.
  • Ein Drei-Knopf-Modal im SQL Editor, das CREATE TABLE-Statements abfängt (PR #45008) – der Standard-Klickpfad erzeugt weiterhin Tabellen ohne RLS, erst das explizite "Run and enable RLS" schützt.
  • Warnhinweise im Table Editor, E-Mail-Alerts bei RLS-off-Tabellen und neue Splinter-Lints im Security Advisor (Splinter-Repo).
  • Der REST-OpenAPI-Schemadump unter /rest/v1/ wurde auf Cloud plattformweit geschlossen (401 für alle Key-Formate). Das erschwert das Aufzählen von Tabellen – blockiert aber nicht den Zugriff auf die Daten pro bekannter Tabelle.
  • Die offizielle RLS-Dokumentation wurde im April 2026 auf "RLS by default" umgeschrieben (PR #42969) – allerdings als reine Docs-Änderung; der Postgres-Upstream-Default (CREATE TABLE ohne RLS) bleibt unverändert.
Diese Maßnahmen erreichen keine CLI-Migrations, ORM-Generatoren, pg_dump/restore-Pipelines oder KI-Builder-Scaffolds – genau die Pfade, über die das Muster in der Praxis am häufigsten entsteht.

Zwei Key-Formate, eine Realität. Supabase hat im Juni 2025 ein neues Key-Format eingeführt. Der alte Key (anon) beginnt mit eyJ... und ist ein JWT-Token. Der neue Key (publishable) beginnt mit sb_publishable_... und ist ein kurzer opaker String. Beide sind für den Einsatz im Frontend gedacht, beide schützen Ihre Daten nicht ohne RLS. Supabase schreibt selbst: "These keys do not protect against code analysis, browser inspection, or CSRF attacks." Bis Ende 2026 werden die alten JWT-Keys (laut Supabase) abgeschaltet.

Verbreitung. Seit 2025 ist CVE-2025-48757 bekannt: 170+ öffentlich dokumentierte Lovable-Apps mit exponierten Datenbanken. Betroffen sind insbesondere Apps, die mit sog. Vibe-Coding-Tools wie Lovable, Bolt, v0 (Vercel), Replit Agent oder Cursor erstellt werden – dort legen End-Nutzer, die keine Entwickler sind, Tabellen über einen KI-Assistenten an und sehen den Dashboard-Warntext nie. Bei eigenen Recherchen zu deutschsprachigen Webseiten fanden sich u.a. Namen, E-Mail-Adressen, Telefonnummern, Bankverbindungen (IBAN), Geburtsdaten, Steuernummern und in Einzelfällen Sozialversicherungsnummern als öffentlich lesbar exponiert.

Weiterführende Primärquellen:
✅ Was dieses Tool tut:
  • Ermittelt Tabellennamen Ihrer Supabase-Instanz – primär über das REST-OpenAPI-Verzeichnis (bei self-hosted oder älteren Projekten), Fallback 1: GraphQL-Introspection (/graphql/v1), Fallback 2: manuelle Eingabe.
  • Prüft pro Tabelle (GET /rest/v1/<tabelle>?limit=10), ob sie mit Ihrem öffentlichen Anon-Key lesbar ist.
  • Zeigt Status pro Tabelle: lesbar (RLS fehlt oder permissiv), verweigert (RLS aktiv oder GRANT entzogen) oder nicht gefunden.
  • Erzeugt auf Wunsch einen HTML-Report mit Handlungsempfehlungen zum lokalen Download.
  • Läuft vollständig im Browser (client-side JavaScript, keine externen Libraries, keine Analytics, kein Backend).
⚠️ Was dieses Tool NICHT tut (Stand April 2026):
  • Keine Speicherung – überhaupt nirgendwo: weder URL, Key noch Scan-Ergebnisse verlassen Ihren Browser. Die Kommunikation erfolgt direkt zwischen Browser und Ihrer Supabase-Instanz.
  • Keine Umgehung von Zugangssicherung (§ 202a StGB): der Anon-Key ist von Supabase ausdrücklich als öffentlich vorgesehen und im Frontend-Quellcode Ihrer App eingebettet. Es werden nur Endpunkte abgefragt, die Supabase über diesen Key anbietet.
  • Keine automatische Schema-Aufzählung auf aktuellen Cloud-Projekten: seit dem 2025 Security-Retro ist der OpenAPI-Dump /rest/v1/ plattformweit geschlossen – für alle Key-Formate, auch den Legacy-Key eyJ.... Das Tool fällt daher auf GraphQL-Introspection oder manuelle Eingabe von Tabellennamen zurück. Liefern beide Pfade nichts, bleibt das Tool erkenntnislos – das heißt nicht, dass Ihre Instanz sicher ist.
  • Kein Scanner, keine Wortlisten, kein Brute-Forcing von Tabellennamen. Das Tool setzt voraus, dass Sie Eigentümer:in der geprüften Instanz sind.
  • Maximal 10 Zeilen pro Tabelle als Stichprobe – keine Vollkopie, keine Aggregation über mehrere Projekte.
  • Erkennt nicht: self-hosted Supabase/PostgREST (eigener Server statt supabase.co), API-Keys die erst nach Login geladen werden, stark obfuskierter JavaScript-Code, fehlkonfigurierte RLS-Policies à la USING (true), SECURITY DEFINER-Funktionen mit public-Grants, postgres_changes-Leaks über Realtime, Edge-Function-Leaks, service_role-Keys die fälschlich im Frontend eingebettet sind.
  • Ein negatives Ergebnis bedeutet nicht automatisch, dass alles sicher ist – das Tool deckt nur die häufigsten, direkt über die REST-API erreichbaren Muster ab. Eine umfassendere Liste an Vektoren findet sich in der öffentlichen Dokumentation unter github.com/atraining/odradek.

Schritt 1: Supabase-Daten finden

Methode A - Bookmarklet (kein technisches Wissen nötig)

Ziehen Sie den blauen Button unten in Ihre Lesezeichenleiste. Öffnen Sie dann Ihre Webseite und klicken Sie auf das Lesezeichen. Die Werte werden Ihnen in Dialogfeldern zum Kopieren angezeigt.

🔍 Supabase Check ← In Lesezeichenleiste ziehen

Methode B - Browser Console

Öffnen Sie Ihre Webseite → F12 → Console → Code einfügen → Enter:

(async()=>{const R=/https:\/\/([a-z0-9]+)\.supabase\.co/,K=/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+|sb_publishable_[a-zA-Z0-9_-]+/g,f=new Set,r=new Set,log=(u,k)=>{if(u)r.add(u[1]);if(k)[...new Set(k)].forEach(x=>f.add(x))};const h=document.documentElement.innerHTML;log(h.match(R),h.match(K));for(const s of document.querySelectorAll('script[src]')){try{const t=await fetch(s.src).then(r=>r.text());log(t.match(R),t.match(K))}catch{}}if(f.size||r.size){const ref=[...r][0]||'-';const key=[...f][0]||'-';console.log('%c Supabase gefunden! ','background:#22c55e;color:white;padding:4px 8px;border-radius:4px','\n Project Ref: '+ref+'\n Anon Key: '+key);prompt('Project Ref:',ref);prompt('Anon Key:',key)}else{console.log('%c Kein Supabase ','background:#ef4444;color:white;padding:4px 8px;border-radius:4px')}})()

Methode C - Supabase Dashboard

Im Supabase Dashboard: Settings → General → Reference ID und Settings → API → anon public Key (Legacy: beginnt mit eyJ...) oder Publishable Key (Neu: beginnt mit sb_publishable_...).

Schritt 2: Sicherheitscheck

Scan läuft...

Was tun wenn betroffen?

Wenn der Scan oben lesbare Tabellen zeigt, ist die Datenbank aus dem offenen Internet abrufbar. Unten ein pragmatischer Incident-Response-Ablauf in fünf Phasen. Bei hochsensiblen Daten (Gesundheit, Finanzen, amtliche Nummern): erst Phase 1 (Zugriff stoppen), dann Phase 2 (Logs prüfen), dann debuggen.

Phase 1 – Sofort: Zugriff unterbrechen (0–60 Min)
Wählen Sie die Option, die zum Kontext passt:
  • Data API abschalten (schnellster Eingriff, ein Klick): Dashboard → Settings → API → Data API deaktivieren. Blockiert alle PostgREST-Anfragen mit dem Anon-Key. Ihre App läuft danach ohne Daten – Angreifer sind aber ebenso ausgesperrt.
  • Anon-Key rotieren: Dashboard → Settings → API → neuen Anon-Key erzeugen. Der alte Key im Frontend funktioniert nicht mehr; Ihre App muss neu deployed werden, bevor sie wieder läuft.
  • Projekt pausieren (bei hochsensiblen Daten oder Verdacht auf aktive Exfiltration): Dashboard → Settings → General → Pause project. Kein Lesen, kein Schreiben, bis Sie entpausieren.
  • Self-hosted: PostgREST-Service stoppen (docker compose stop rest) oder den Port in der Firewall blocken, bis Sie Phase 4 abgeschlossen haben.

Phase 2 – Log-Review: Ausmaß prüfen (1–4 Std)
  • Dashboard → Logs → API Edge Logs oder Postgres Logs (je nach Plan). Nach der betroffenen Tabelle filtern.
  • Typisches Exfiltrations-Muster: eine IP oder wenige IPs machen innerhalb weniger Minuten hunderte GET /rest/v1/<tabelle>-Anfragen mit steigendem ?offset= oder Range:-Header. Ungewöhnlich hohes Response-Volumen (Bytes pro Minute) ist ein zweites Signal.
  • Self-hosted: docker logs postgrest und pg_stat_statements; zusätzlich Kong-Logs bei vollständigem Supabase-Stack.
  • Supabase Cloud zeigt im Free/Pro-Plan typischerweise nur 1–7 Tage Logs. Länger zurückliegende Zugriffe lassen sich ggf. nur über Supabase Support rekonstruieren (siehe Phase 3).

Phase 3 – Supabase kontaktieren (nur bei Verdacht auf tatsächlichen Abfluss)
  • Free/Pro: Dashboard → Support-Button, oder support@supabase.com.
  • Team/Enterprise: über Ihren Account Manager.
  • Betreff-Vorschlag: "Suspected unauthorized access via missing RLS – request access log correlation for project <ref>."
  • Ohne konkreten Verdachtsfall wird Support keine Logs proaktiv herausgeben. Formulieren Sie den Verdacht mit Zeitfenster, betroffenen Tabellen und bekannten Indikatoren (IPs, Volumen).

Phase 4 – Root-Cause beheben (RLS & Grants)
Für jede betroffene Tabelle in der Supabase SQL Console: 
ALTER TABLE public.ihre_tabelle ENABLE ROW LEVEL SECURITY;

-- Default-Deny: ohne Policies gibt die Tabelle keine Zeilen zurück.
-- Minimalbeispiel – nur authentifizierte Nutzer lesen ihre eigenen Zeilen:
CREATE POLICY "own_rows_select" ON public.ihre_tabelle
  FOR SELECT TO authenticated
  USING (user_id = auth.uid());

CREATE POLICY "own_rows_insert" ON public.ihre_tabelle
  FOR INSERT TO authenticated
  WITH CHECK (user_id = auth.uid());
Zusätzlich prüfen:
  • Fehlkonfigurierte Policies: USING (true) – lässt jede Zeile durch, sobald ein beliebiger Nutzer angemeldet ist. In der Praxis ebenso kritisch wie fehlendes RLS.
  • Views: ohne security_invoker = true umgehen sie RLS. Auf Postgres 15+ explizit ALTER VIEW <view> SET (security_invoker = true); setzen.
  • Edge Functions, die intern den service_role-Key nutzen, dürfen keine ungeprüften Anon-Eingaben in Queries einsetzen.
  • Realtime / postgres_changes: RLS-off-Tabellen leaken jede Änderung live an anonyme Subscriber. Tabelle entweder aus der supabase_realtime-Publication entfernen oder RLS aktivieren.
  • Splinter-Lints: Dashboard → Database → Advisors → Security Advisor. Insbesondere Lint 0013_rls_disabled_in_public.

Phase 5 – Meldepflicht prüfen (DSGVO)
Falls personenbezogene Daten betroffen waren: als Verantwortlicher (Art. 4 Nr. 7 DSGVO) sind Sie – nicht Supabase – zur Meldung verpflichtet. Supabase ist Auftragsverarbeiter (Art. 4 Nr. 8 DSGVO).
  • Art. 33 DSGVO: Meldung an die zuständige Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden.
  • Art. 34 DSGVO: Bei hohem Risiko müssen auch die betroffenen Personen informiert werden.
  • Zuständige Behörde finden: datenschutzkonferenz-online.de.
  • Die Meldung muss gemäß DSGVO durch Sie als Verantwortlicher selbst erfolgen – externe Meldungen (durch Dritte, Presse) ersetzen die Pflicht nicht.

Validieren
Nach Phase 4 den Scan oben erneut starten. Zuvor lesbare Tabellen müssen jetzt als verweigert erscheinen. Zusätzlich auf SQL-Seite: 
SELECT c.relname, c.relrowsecurity
FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public' AND c.relkind = 'r';
-- relrowsecurity muss für jede Tabelle true sein.
Weiterführend: Row Level Security Guide · Securing Your Data · Splinter-Linter.

Häufige Fragen

Ist das Hacking?

Nein. Der Supabase "anon Key" ist von Supabase dafür vorgesehen, im Frontend eingebettet zu werden. Er ist öffentlich sichtbar im Quellcode - das kann jeder mit F12 → Sources sehen. Das Problem ist nicht der Key, sondern fehlende Row Level Security auf den Tabellen.

Werden meine Daten gespeichert?

Nein. Alles läuft in Ihrem Browser. Kein Server ist beteiligt. Ihr Project Ref, Ihr Key und die Scan-Ergebnisse verlassen nie Ihren Computer. Sie können den Netzwerk-Tab in den Entwicklertools überprüfen - die einzigen Requests gehen direkt an Ihre eigene Supabase-Instanz.

Bin ich automatisch betroffen wenn ich Supabase nutze?

Nein. Wenn Sie Row Level Security (RLS) auf allen Tabellen aktiviert haben, sind Sie geschützt. Dieser Check prüft genau das.

Der Report zeigt personenbezogene Daten - was soll ich tun?

Behandeln Sie den Report vertraulich. Aktivieren Sie sofort RLS auf den betroffenen Tabellen. Als Verantwortlicher im Sinne der DSGVO sind Sie verpflichtet, die zuständige Aufsichtsbehörde innerhalb von 72 Stunden zu informieren (Art. 33 DSGVO). Supabase ist Auftragsverarbeiter - die Meldepflicht liegt bei Ihnen, nicht bei Supabase. Löschen Sie den Report nach Behebung der Schwachstelle.

Was erkennt dieses Tool nicht?
  • Self-hosted PostgREST/Supabase (eigener Server statt supabase.co)
  • API-Keys die erst nach Login geladen werden
  • Stark obfuskierter oder gesplitteter JavaScript-Code
  • Ein negatives Ergebnis bedeutet nicht automatisch dass alles sicher ist
Mein Scan zeigt "0 Zeilen" - bin ich trotzdem gefährdet?

Möglicherweise ja. Auch wenn Ihre Tabellen aktuell leer sind, ist das Datenbankschema (Tabellennamen, Spaltennamen, Datentypen) öffentlich einsehbar. Das ist ein Sicherheitsrisiko weil:
• Angreifer sehen wie Ihre Daten strukturiert sind (z.B. password_history, user_tokens, iban)
• Das erleichtert gezielte SQL-Injection-Angriffe wenn andere Schwachstellen existieren
• Sobald Daten in die Tabellen geschrieben werden, sind sie sofort öffentlich lesbar
• OWASP klassifiziert das als "Security Misconfiguration" (A05:2021)

Empfehlung: Aktivieren Sie RLS auch auf leeren Tabellen – bevor die ersten Daten eingegeben werden.

Wie verbreitet ist dieses Problem?

Sehr. Laut Sicherheitsforschern sind 11% aller Indie-Apps betroffen. CVE-2025-48757 dokumentierte 170+ betroffene Lovable-Apps. In meiner eigenen Untersuchung von ca. 600 deutschsprachigen Webseiten waren über 350 zugreifbar.

Rechtlicher Hinweis: Dieses Tool führt ausschließlich passive Prüfungen gegen Ihre eigene Supabase-Instanz durch. Es werden nur Endpunkte abgefragt die mit dem von Ihnen eingegebenen öffentlichen API-Key erreichbar sind. Es wird keine Zugangssicherung im Sinne von §202a StGB umgangen.

Risiko-Klassifizierung: Die Labels HIGH/MEDIUM/LOW basieren auf Tabellennamen und Dateninhalt-Mustern (z.B. Erkennung von E-Mail-Adressen). Die Klassifizierung ist regelbasiert und kann unzuverlässig sein - prüfe die Ergebnisse immer manuell.

Keine Gewährleistung: Dieses Tool wird ohne Garantie bereitgestellt. Ich übernehme keine Haftung für die Ergebnisse, deren Vollständigkeit oder daraus abgeleitete Handlungen.

Datenschutz: Ich erhebe, speichere und übermittle keine Daten. Der Scan läuft vollständig im Browser (client-side JavaScript). Die Kommunikation erfolgt direkt zwischen Ihrem Browser und Ihrer Supabase-Instanz. Der Quellcode dieser Seite ist vollständig einsehbar (Rechtsklick → Seitenquelltext anzeigen).