Ist mein Supabase oder Firebase sicher konfiguriert? Ein Selbsttest
Kurz gesagt: Supabase und Firebase geben Ihrer App direkten Zugriff auf die Datenbank, und genau das macht sie schnell und riskant zugleich. Der Schutz vor fremden Zugriffen liegt bei Supabase in den Row-Level-Security-Regeln und bei Firebase in den Security Rules. Sind diese nicht bewusst eng gesetzt, kann im schlimmsten Fall jeder, der die Adresse Ihrer Datenbank kennt, Ihre Daten lesen oder verändern, auch ohne Login. Das ist die häufigste ernste Lücke in KI-Prototypen, und Sie können in wenigen Minuten prüfen, ob Sie betroffen sind.
Wenn Sie mit einem dieser Dienste gebaut haben und nie bewusst Regeln geschrieben haben, lohnt sich der Selbsttest weiter unten sofort.
Warum diese Dienste anders funktionieren als klassische Backends
Bei klassischer Software liegt zwischen dem Nutzer und der Datenbank ein Server, der jede Anfrage prüft. Supabase und Firebase drehen das um. Die App im Browser spricht die Datenbank oft direkt an, ohne dass zwingend ein eigener Server dazwischenliegt. Das ist der Grund, warum man damit so schnell vorankommt, und zugleich der Grund für das Risiko. Wenn die App die Datenbank direkt anspricht, muss die Datenbank selbst entscheiden, wer was darf. Diese Entscheidung treffen die Zugriffsregeln, und wenn die nicht gesetzt sind, entscheidet die Datenbank im Zweifel zu großzügig.
Was Row Level Security und Security Rules wirklich tun
Man kann sich diese Regeln wie den Türsteher der Datenbank vorstellen. Ohne Türsteher kommt jeder herein, der die Adresse kennt. Der Türsteher entscheidet für jede einzelne Zeile in Ihrer Datenbank, ob dieser konkrete Nutzer sie sehen, ändern oder löschen darf. Ein Beispiel: In einer sauber geregelten Datenbank darf ein Kunde nur seine eigenen Bestellungen sehen, nicht die aller anderen. Fehlt die Regel, sind alle Bestellungen für jeden abrufbar, der weiß, wie man fragt.
Das Tückische ist, dass Ihre App auch ohne diese Regeln völlig normal aussieht. Die Oberfläche zeigt jedem Nutzer brav nur seine eigenen Daten, weil die App im Browser so programmiert ist. Nur schützt diese Höflichkeit der Oberfläche nichts. Wer die Datenbank direkt anspricht, umgeht die Oberfläche und trifft auf den fehlenden Türsteher.
Der Selbsttest in drei Schritten
Sie brauchen dafür keine Entwicklererfahrung, nur Zugang zu Ihrer Projektkonsole.
Erstens, prüfen Sie, ob Row Level Security überhaupt aktiv ist. In der Supabase-Konsole sehen Sie pro Tabelle, ob RLS eingeschaltet ist. Steht dort für Tabellen mit echten Daten „disabled“, ist das ein deutliches Warnsignal. Bei Firebase öffnen Sie die Rules und schauen, ob dort etwas steht, das echten Zugriff einschränkt, oder ob alles auf erlaubt steht.
Zweitens, achten Sie auf die berüchtigte Allow-all-Regel. Bei Firebase ist eine Regel, die Lesen und Schreiben für alle erlaubt, das digitale Äquivalent einer offenen Haustür. Genau diese Regel schlägt der Schnellstart oft vor, damit im Test nichts im Weg ist, und genau diese Regel bleibt dann stehen.
Drittens, prüfen Sie, wo Ihre Zugangsschlüssel liegen. Der öffentliche Schlüssel darf im Frontend stehen, der geheime Schlüssel niemals. Findet sich der geheime Schlüssel im Code, den der Browser lädt, kann jeder Besucher mit ihm sämtliche Zugriffsregeln umgehen. Dann helfen auch gute Regeln nicht mehr.
Wenn einer dieser drei Punkte unklar oder rot ist, haben Sie kein Wissensproblem mehr, sondern eine konkrete Baustelle.
Warum das oft niemandem auffällt, bis es zu spät ist
Eine offene Datenbank verhält sich still. Sie meldet sich nicht, sie verlangsamt nichts, sie zeigt keine Fehlermeldung. Für Ihre Nutzer und für Sie sieht alles perfekt aus. Der Zustand wird erst sichtbar, wenn jemand ihn ausnutzt, und dann ist es kein Warnhinweis mehr, sondern ein Datenabfluss. Deshalb ist die Prüfung im Voraus so viel billiger als die Reaktion danach. Sie schauen einmal nach, statt später zu erklären, warum Kundendaten abgeflossen sind.
Wie man es richtig setzt, ohne die Geschwindigkeit zu verlieren
Sichere Zugriffsregeln bedeuten nicht, dass Sie langsamer werden. Sie bedeuten, dass Sie einmal sauber definieren, wer was darf, und danach mit derselben Geschwindigkeit weiterbauen, nur eben ohne offene Tür. In einem Audit gehen wir jede Tabelle durch, setzen die Regeln passgenau auf die tatsächlichen Rollen Ihrer Nutzer, prüfen die Lage der Schlüssel und testen anschließend gezielt, ob der fremde Zugriff wirklich blockiert ist. Oft hinterlegen wir dabei Vorlagen und Regeln für Ihre KI-Sessions, damit neue Tabellen von Anfang an geschützt entstehen und die Lücke nicht bei der nächsten schnellen Session zurückkehrt.
Unsicher, ob Ihre Datenbank offen steht? Wir prüfen im Vibecode-Audit Ihre Zugriffsregeln, die Lage der Schlüssel und die tatsächlichen Zugriffe, und schließen offene Türen, bevor jemand sie findet.