Kann jeder deine Supabase-Datenbank lesen? 3.680 Apps im Test

Deine App hat einen Login. Dahinter liegen deine Nutzer, ihre Nachrichten, vielleicht ihre Bestellungen. Das wirkt privat, und es gibt keinen naheliegenden Weg herauszufinden, ob es das auch ist. Die Supabase-Konsole ist kein Ort, an den du je gehen musstest.

Also haben wir es an den Apps anderer Leute gemessen. Im August 2026 haben wir 30.998 aktive Apps gescannt, veröffentlicht mit Lovable, Base44, Replit, v0 und Bolt, und jeder davon eine Frage gestellt: kann jeder deine Supabase-Datenbank ohne Login lesen?

Bei 2.096 der 3.680 Apps, bei denen wir eine klare Antwort bekamen: ja.

Und hier ist der Teil, den sowohl die alarmierende als auch die beruhigende Version dieser Geschichte falsch erzählt. Eine offene Tabelle ist nicht automatisch ein Leck. Viele Tabellen sollen von allen gelesen werden. Welche Tabelle es ist, entscheidet alles, und das kann nur die Person beantworten, die die App gebaut hat. Deshalb fällt es auch niemandem auf: Die App funktioniert so oder so einwandfrei.

Kann jeder deine Supabase-Datenbank lesen?

Bei mehr als der Hälfte der Apps, die wir prüfen konnten, ja: Mindestens eine Tabelle lieferte Zeilen an eine Anfrage ohne jeden Login.

Dass das überhaupt geht, hat nichts damit zu tun, dass etwas kaputt wäre. Deine App spricht aus dem Browser deiner Besucher mit Supabase, trägt also einen Schlüssel bei sich, den jeder Besucher lesen kann, und dieser Schlüssel soll öffentlich sein. Er nennt dein Projekt. Er gewährt für sich genommen nichts.

Was entscheidet, ob ein Fremder an deine Daten kommt, ist Row Level Security: eine Regel pro Tabelle, die sagt, wer welche Zeilen lesen darf. Ohne Regel ist der Schlüssel das Einzige, was zwischen dem Internet und dieser Tabelle steht, und der Schlüssel steht in deiner Seite.

Genau das haben wir gemessen. Nicht, ob ein Schlüssel sichtbar war (das ist er immer), sondern was die Datenbank tut, wenn ihn jemand benutzt.

Wovon die 57 % ein Anteil sind

Von einer Grundmenge, die wir dreimal verkleinert haben, und diese Verkleinerung zählt mehr als die Schlagzeile.

Drei Dinge haben wir nicht getan. Jedes davon verschiebt die echte Zahl in die eine oder andere Richtung, und es gehört genannt statt vergraben.

Wir haben nur nach Tabellennamen gefragt, die wir sehen oder erraten konnten. Ein veröffentlichbarer Schlüssel darf die Tabellen eines Projekts bei Supabase nicht mehr auflisten. Also haben wir die Namen gelesen, die eine App im eigenen Code nennt, und zwei Dutzend gewöhnliche ergänzt, begrenzt auf dreißig pro App. Eine App, deren Tabellen anders heißen, als uns eingefallen ist, sieht für uns sauber aus und ist es vielleicht nicht.

Wir haben Zeilen gezählt, nie gelesen. Jede Abfrage hat die Datenbank gefragt, wie viele Zeilen sie herausgeben würde, und dort aufgehört. Es wurden keine Daten heruntergeladen, und keine App wird in diesem Artikel oder sonst wo bei uns namentlich genannt.

Fast alle Apps, die wir prüfen konnten, waren Lovable-Apps. Sie sind der größte Teil dessen, was wir gescannt haben, und nennen ihr Supabase-Projekt am ehesten in der Seite. Lies das also als Messung von Lovable-Apps mit Supabase, nicht von jedem Builder. Wo die Prüfung nicht durchlief, haben wir festgehalten, dass sie nicht durchlief. Eine App, die wir nicht prüfen konnten, ist unbekannt, nicht sauber.

Eine offene Tabelle ist nicht automatisch ein Loch

Von außen sieht eine für alle lesbare Tabelle gleich aus, ob darin dein Produktkatalog steht oder deine Kundschaft. Die Antwort ist dieselbe. Nur der Name ist anders.

Deshalb teilen wir den Befund in zwei. Bei 394 dieser Apps trug eine der lesbaren Tabellen einen Namen aus einer kurzen Liste, die für uns Menschen bedeutet: users, profiles, customers, orders, messages, invoices. Das ist ein Fremder, der deine Kundschaft liest, und es gehört heute repariert.

Die anderen 1.702 können wir von außen nicht beurteilen, und kein anderer Scanner kann das auch. Eine Tabelle posts kann ein öffentlicher Blog sein oder private Notizen. Du weißt, welches von beidem. Niemand, der deine App aus dem Internet ansieht, weiß es.

Wenn du bei deiner eigenen App nicht raten willst: Unser kostenloser Scan prüft deine Live-Seite von außen und sagt dir, welche Tabellen geantwortet haben. Er dauert etwa 20 Sekunden und braucht kein Konto: App scannen.

Warum das Apps trifft, die niemand absichtlich geöffnet hat

Weil die Reparatur, die eine kaputte App wieder zum Laufen bringt, meistens die ist, die die Tabelle öffnet.

Der Ablauf sieht so aus. Row Level Security wird angeschaltet, von dir oder vom Builder. Deine App zeigt sofort keine Daten mehr, denn angeschaltet ohne Regeln heißt, dass die Datenbank alle abweist, dich eingeschlossen. Du schickst den Fehler an deinen Assistenten, der schreibt eine Policy, die jede Anfrage erlaubt, und die App läuft wieder. Danach sieht nichts mehr falsch aus.

Genau diese Policy finden wir. Das Dashboard meldet die Tabelle als geschützt, weil der Schalter an ist und eine Policy existiert. Der Artikel darüber, warum angeschaltete Row Level Security nicht dasselbe ist wie geschützt, geht die vier möglichen Zustände einer Tabelle durch und zeigt, wie du deinen erkennst.

Das Leck, vor dem alle warnen, war das seltene

In allen 30.998 Apps kam ein geheimer Supabase-Schlüssel im Browser (der Schlüssel, der jede von dir geschriebene Regel ignoriert) 3-mal vor.

Es ist das Leck, von dem Betreiber ständig hören, und das, was wir am seltensten gefunden haben. Es ist ernst, wenn es passiert, und es lohnt sich zu wissen, wie man es erkennt, aber dort investierte Sorge bewacht eine Tür, die fast immer zu ist. Die gewöhnliche Öffnung in diesen Apps ist eine ganz normale Tabelle ohne Regel.

So prüfst du deine eigene App

Zwei Stellen in deiner Supabase-Datenbank, und ein Weg, sie von dort aus zu sehen, wo ein Fremder steht.

Öffne den Security Advisor in deinem Supabase-Dashboard. Er listet jede Tabelle auf, bei der Row Level Security ausgeschaltet ist, und das ist die deutlichste Variante dieses Problems. Supabase weist gut darauf hin, und wenn dein Projekt auf dieser Liste steht, hast du deine Antwort, ohne eine Zeile SQL zu lesen.

Lies danach die Policies jeder Tabelle, in der Menschen stehen. Der Advisor kann nicht entscheiden, ob eine großzügige Policy Absicht ist. Bei einem Produktkatalog wäre sie richtig. Öffne die Tabelle, sieh dir die Policy an und prüfe, ob sie eine Bedingung nennt oder allen erlaubt.

Oder prüfe es von außen, denn dort liegt das Risiko. Ein Fremder öffnet dein Dashboard nicht. Unser kostenloser Scan stellt dieselbe anonyme Anfrage wie ein Außenstehender und meldet, welche Tabellen geantwortet haben: App scannen, kein Konto, keine Installation.

Was du mit einer Tabelle machst, die nicht lesbar sein sollte

Das einmal zu prüfen, ist ein Abend. Die Antwort auch nächsten Monat richtig zu halten, ist der Teil, der nicht in einen Abend passt, und dafür haben wir Reeve Care gebaut. Es wiederholt genau diese Prüfung nach Zeitplan auf deiner App und schreibt dir eine E-Mail, wenn die Antwort schlechter wird, denn eine Tabelle, die im März zu war und im Juni offen ist, fällt von innen niemandem auf.

Reeve Care führt außerdem eigene Backups deiner Supabase-Datenbank, nach Zeitplan angelegt, außerhalb deines Supabase-Kontos gelagert und zur Prüfung zurückgelesen, bevor sie zählen, mit einer Wiederherstellung, die den aktuellen Stand sichert, bevor sie irgendetwas einspielt. Diese zweite Hälfte zählt hier, weil wir immer nur das Lesen prüfen. Dieselbe großzügige Regel kann auch Schreiben erlauben, und ein Fremder, der in deine Tabelle schreibt, ist die Variante, die sie leert, und dann ist eine Kopie von vorher das Einzige, was die Zeilen zurückbringt. Care deckt deine Datenbank ab, und die in Storage hochgeladenen Dateien, sobald du sie verbindest, auf Supabase und nicht auf jeder Art von Datenbank: was es beobachtet und was es kostet.

Wenn du das lieber als Liste durchgehst: Die 10-Minuten-Sicherheitscheckliste deckt das zusammen mit den anderen Dingen ab, die in einer frisch gestarteten App zu schließen sind. Und falls eine Tabelle eine Weile offen stand, hängt das, was du später rückgängig machen kannst, vollständig davon ab, was du gesichert hast.