Die Sicherheits-Checkliste für Vibe-Coding, in neun Prüfungen

Du willst gleich jemandem die Adresse deiner App schicken, und eine leise Stimme sagt, du solltest vorher nachsehen. Also suchst du nach einer Sicherheits-Checkliste für Vibe-Coding und findest eine mit fünfundzwanzig Punkten, geschrieben von jemandem, der annimmt, du wüsstest bereits, was eine Content Security Policy ist.

Hier ist der Teil, den Liste um Liste falsch macht: das meiste darauf lässt sich gar nicht prüfen. "Nimm starke Passwörter" ist ein Ratschlag. "Räum toten Code auf" ist Hausarbeit. "Folge dem Prinzip der geringsten Rechte" ist ein Satz. Keiner davon hat einen Test, also lässt sich keiner abschließen, und eine Liste, die du nicht abschließen kannst, ist eine Sorge mit Nummern daran.

Diese hier hat neun Punkte. Neun ist die Zahl der Dinge, die sich an einer laufenden App von außen nachprüfen lassen, ohne dein Passwort, dein Repository oder dein Supabase-Konto. Jeder Punkt hat einen Test, den du selbst machen kannst, und jeder Test kommt mit ja oder nein zurück.

Stell es dir vor wie den Rundgang, den ein Pilot vor dem Flug um ein Flugzeug macht. Er ist kurz, alles darauf ist vom Vorfeld aus sichtbar, und er ersetzt nichts aus dem Wartungsbuch. Der letzte Abschnitt dieses Beitrags handelt vom Wartungsbuch.

Was gehört auf eine Sicherheits-Checkliste für Vibe-Coding?

Neun Fragen, und es sind die neun, die ein Fremder heute Nachmittag über deine App stellen könnte, ob du nachgesehen hast oder nicht.

Unser eigener kostenloser Sicherheitsscanner prüft alle neun an jeder laufenden URL in etwa 20 Sekunden ohne Konto, und das ist der schnellste Weg für den ersten Durchgang. Er liest, er meldet sich nie an, und er schreibt nie etwas. Jeder Punkt weiter unten bleibt etwas, das du von Hand prüfen kannst, und die Tests stehen ausgeschrieben da, damit du eine Zeile unseres Berichts gegen dein eigenes Dashboard halten kannst.

Die vier vor dem Teilen der Adresse

Geheime Schlüssel, Datenbankregeln, private Dateien und Storage-Buckets. Bei diesen vier sind es deine Daten oder dein Geld, die offenliegen, und alle vier gehören dir zum Reparieren und nicht deiner Hosting-Plattform.

Drei davon sind die einzigen Prüfungen im ganzen Satz, die einen kritischen Befund melden können, und die vierte ist die, bei der offenliegt, was deine Nutzer hochgeladen haben. Zwischen dem 12. und 14. August 2026 haben wir alle neun Prüfungen über 30.998 laufende vibe-gecodete Apps laufen lassen, und die Zahlen in jedem Abschnitt unten stammen aus diesem Lauf.

1. Steckt ein geheimer Schlüssel im ausgelieferten Code?

Durchsuche dein ganzes Projekt nach sk_, sb_secret_, service_role und AKIA. Ein Treffer in irgendetwas, das der Browser herunterlädt, ist der Befund.

Alles, was deine App zum Laufen im Browser braucht, kommt in diesem Browser an, also kommt auch ein Schlüssel darin an. Manche Schlüssel gehören dorthin: ein Supabase-Schlüssel mit anon oder sb_publishable_ ist eine Adresse und keine Berechtigung, und ihn zu finden ist richtig. Welche Schlüssel im Frontend sicher sind und welche nicht ist dieser Unterschied in voller Länge.

Ein geheimer Schlüssel ist die andere Sorte. Ein Supabase-Schlüssel mit sb_secret_ oder service_role ignoriert jede Tabellenregel, die du je geschrieben hast. Ein Stripe-Schlüssel mit sk_live_ bewegt Geld. Wir haben einen Schlüssel dieser Klasse auf 52 von 30.998 Apps gefunden, was selten ist und das Schlimmste auf dieser Liste, wenn es passiert. Falls deiner dazugehört, rotiere ihn, bevor du sonst etwas tust: den Schlüssel aus dem Code zu löschen lässt den alten Wert weiterlaufen.

2. Kann ein Fremder deine Datenbank lesen?

Öffne in Supabase den Security Advisor. Jeder Eintrag, der sagt, eine Tabelle sei öffentlich, aber die Zeilensicherheit sei nicht aktiviert, ist eine Tabelle, die jedem antwortet, der fragt, und genau diese Warnung hat einen eigenen Beitrag.

Row Level Security ist die Regel, die Zeile für Zeile entscheidet, wer was sehen darf. Ohne sie reicht der öffentliche Schlüssel in deiner App, um die Tabelle zu lesen, und dieser Schlüssel steckt von Haus aus im Browser jedes Besuchers.

Das ist der häufigste ernste Befund im ganzen Satz: 2.096 von 3.680 Apps, deren Supabase-Projekt uns geantwortet hat, also 57 %, gaben mindestens eine Tabelle an eine Anfrage ohne Anmeldung heraus. Sie für jede Tabelle einzuschalten ist die Reparatur. Der Advisor liest deine Einstellungen statt der Antworten deiner Datenbank, also prüfe zum Schluss von außen: eine Tabelle kann die Einstellung an haben und eine Regel, die trotzdem jeden durchlässt.

3. Kann jeder deine privaten Dateien herunterladen?

Öffne deineapp.de/.env und deineapp.de/.git/config in einem privaten Fenster. Beide sollten sich nicht öffnen lassen.

Eine .env-Datei ist jeder Schlüssel, den du sicher auf dem Server glaubtest, in einer schlichten Liste, unter einer erratbaren Adresse. Ein .git-Verzeichnis ist die Geschichte deines Projekts. Keines von beiden soll ausgeliefert werden, und gelegentlich werden sie es doch, meist weil ein Build einen Ordner mitkopiert hat, den er nicht hätte mitnehmen sollen.

Das ist das Seltenste, was wir finden: 8 von 30.749 Apps. Es kostet auch fünf Sekunden, es auszuschließen, und es ist der Ort, aus dem die schädlichsten Lecks kommen, wenn es passiert.

4. Listen deine Storage-Buckets auf, was in ihnen liegt?

Öffne in Supabase den Bereich Storage. Lies die Spalte "Public" bei jedem Bucket und öffne dann die Regeln bei jedem Bucket, in dem etwas liegt, das nicht für alle gedacht ist.

Hier laufen zwei verschiedene Dinge nebeneinander, die leicht durcheinander geraten. Ein öffentlicher Bucket liefert jede Datei aus, deren Namen jemand bereits kennt. Ein auflistbarer Bucket gibt die Namen heraus, und damit wird aus "jemand müsste raten" ein Verzeichnis der Uploads deiner Nutzer. Unsere Prüfung testet das Zweite, denn das ist das, was ändert, was ein Fremder tatsächlich tun kann.

792 von 27.269 Apps hatten einen Bucket, der sich uns ohne Anmeldung auflistete. Was ein Fremder aus dieser Liste bekommt ist die lange Fassung, und die Reparatur ist meist ein Schalter plus eine Regel.

Die fünf, die warten können, bis du Nutzer hast

Header, Source Maps, deine eigenen API-Adressen, das Zertifikat und die Domain. Drei davon setzt meist derjenige, der deine App hostet, und zwei davon sind Termine im Kalender.

Keiner von ihnen gibt für sich allein eine Zeile deiner Datenbank heraus, und deshalb stehen sie in der zweiten Gruppe. Einer der fünf lohnt sich früher, wenn deine App ein eigenes Backend hat, und der ist unten markiert.

5. Sind die Browser-Sicherheitsheader eingeschaltet?

Das ist der einzige Punkt der Liste ohne Variante, die aus der Adresszeile läuft. Ein Scan liest sie, oder du öffnest die Entwicklertools deines Browsers, gehst auf den Tab Netzwerk, klickst die erste Anfrage an und liest die Antwortheader.

Es sind kleine Anweisungen an den Browser: lade diese Seite nur über HTTPS, weigere dich, von einer anderen Seite eingerahmt zu werden, rate nicht bei Dateitypen. Ihr Fehlen legt für sich genommen nichts offen. Es nimmt Schutz weg, der andere Angriffe schwerer macht.

Fast niemand besteht diesen Punkt, und fast niemand kann es. 30.756 von 30.981 Apps fehlte mindestens einer, und auf einer Builder-Subdomain gehört die Einstellung der Plattform. Ob du bei deiner etwas tun kannst hängt ganz davon ab, wo deine App gehostet wird.

6. Ist dein Originalquellcode veröffentlicht?

Öffne deine laufende App, öffne die Entwicklertools deines Browsers und sieh dir den Bereich Sources an. Stehen dort deine eigenen Dateien mit dem Code, den du geschrieben hast, und den Kommentaren, die du hinterlassen hast, dann sind die Source Maps mit dem Build rausgegangen.

Eine Source Map ist eine Übersetzungstabelle, die die komprimierte Datei deiner App zurück in lesbaren Code verwandelt. Entwickler nutzen sie, um eine laufende Seite zu debuggen. Ins Internet veröffentlicht heißt sie, dass jeder deine App so lesen kann, wie du sie geschrieben hast.

3.885 von 30.987 Apps haben ihre veröffentlicht. Das ist für sich genommen kein Leck, und es wird eines, wenn im Code etwas steht, von dem du annahmst, niemand würde es lesen. Was eine veröffentlichte Map offenlegt behandelt den Unterschied und die Build-Einstellung, die sie abschaltet.

7. Antworten deine eigenen API-Adressen einem Fremden?

Kopiere eine der API-Adressen deiner App aus dem Netzwerk-Tab und öffne sie dann in einem privaten Fenster, in dem du nicht angemeldet bist. Sieh dir an, was zurückkommt.

Das ist der Punkt, den du vorziehst, wenn deine App ein eigenes Backend hat, denn alles, was eine Adresse einer Anfrage ohne Anmeldung übergibt, ist öffentlich, wie auch immer die Seite davor aussieht. 3.852 von 30.926 Apps hatten mindestens eine.

Die verwandte Einstellung ist CORS, die entscheidet, welche anderen Websites deine App aus dem Browser eines Besuchers aufrufen dürfen. Ein Wildcard dort ist oft in Ordnung und gelegentlich nicht, und welches von beiden du hast lohnt sich zu lesen, bevor du etwas änderst.

8. Läuft dein Zertifikat bald ab?

Klicke auf das Schloss in der Adresszeile, öffne das Zertifikat und lies das Datum bei "Gültig bis".

Fast jeder Hoster erneuert diese automatisch, und fast jeder davon schafft es. 32 von 30.851 Apps hatten ein abgelaufenes, ablaufendes oder nicht vertrauenswürdiges Zertifikat. Wenn es doch scheitert, bekommen Besucher eine seitenfüllende Browser-Warnung, die ihnen sagt, deine Seite sei unsicher, und die meisten gehen dann.

9. Ist deine Domain verlängert?

Melde dich bei deinem Registrar an, lies das Ablaufdatum und prüfe, ob die Autoverlängerung an ist und die Karte dahinter noch gültig.

Das ist der am wenigsten technische Punkt der Liste und der einzige, der deine App vollständig aus dem Internet nehmen kann. 55 von 30.980 Apps hatten eine abgelaufene oder ablaufende Domain. Ein verfallener Name kann außerdem von jemand anderem registriert werden, mitsamt jedem Link, den je jemand darauf gesetzt hat.

Was auf anderen Checklisten steht und keine Sicherheitsprüfung ist

Backups, Fehlerüberwachung, toter Code und Passwortratschläge. Das erste davon kostet dich am ehesten etwas, und es ist keine Sicherheitsprüfung, denn nichts außerhalb deiner App kann sagen, ob du eines hast.

Das ist der ehrliche Grund, warum es unter den neun fehlt. Ein Scanner liest deine laufende Seite; ein Backup ist eine Kopie deiner Datenbank, die woanders liegt, und kein Blick von außen auf deine App kann sagen, ob sie existiert, ob sie aktuell ist oder ob sie sich zurückspielen ließe. Auf deine Liste gehört es trotzdem. Es gehört auf die Art Liste, die du führst, statt auf die, die du durchläufst.

Die eigenen Backups von Supabase hängen von deinem Tarif ab und bleiben in deinem Supabase-Konto, was in Ordnung ist, bis das Problem das Konto ist. Die drei Wege zu einer Kopie, die dir gehört legt dar, was jeder davon abdeckt.

Wenn dir lieber wäre, es passierte ohne dich, dann ist das Reeve Care. Es nimmt eine Kopie deiner Supabase-Datenbank nach einem Zeitplan, den der gewählte Tarif festlegt, in der Einstiegsstufe jede Nacht und in der höchsten bis zu viermal täglich, liest jede Kopie zurück, bevor sie als Backup zählt, und legt sie dorthin, wo Supabase nicht hinkommt. Wie weit du zurückgehen kannst, legt derselbe Tarif fest. Zurückspielen ist ein Knopf, und er nimmt vor dem Start einen Schnappschuss des aktuellen Stands, sodass ein Druck darauf in Panik nicht zerstören kann, was du retten wolltest. Hochgeladene Dateien kommen ebenfalls mit, sobald du einen Storage-Zugang verbindest, der getrennt abgefragt wird, weil er der einzige Schlüssel ist, den wir halten und der schreiben kann: Supabase gibt für Dateien keinen Nur-Lese-Schlüssel heraus. Care beginnt bei €49 im Monat für eine App, und das ist ein Listenpreis, also liegt die Preisseite manchmal unter dem Wert hier und nie darüber. Wie eine Kopie genommen, geprüft und zurückgespielt wird, ist Schritt für Schritt auf der Supabase-Backup-Seite gezeichnet.

Der Rest dessen, was diese Listen tragen, ist echte Arbeit und nicht diese Arbeit. Fehlerüberwachung sagt dir, wenn deine App kaputtgeht, und das ist Betrieb. "Unbenutzte Abhängigkeiten entfernen" ist Hausarbeit. "Nimm starke Passwörter" gilt für alles, wo du dich je eingeloggt hast.

Wie oft sollte ich das wiederholen?

Nach jedem Deploy, der deine Datenbankregeln, deine Schlüssel oder deine Build-Einstellungen berührt hat. Falls das nach den meisten Deploys klingt: ist es auch, und darin liegt das eigentliche Problem einer Checkliste, die du einmal durchgehst.

Der Rundgang findet genau deshalb vor jedem Flug statt. Row Level Security wird um Mitternacht abgeschaltet, damit eine Seite lädt, und niemand schaltet sie wieder ein. Ein Schlüssel wird ins Frontend eingefügt, um vor einer Demo ein Feature auszuliefern. Ein Bucket wird für einen Upload geöffnet und bleibt offen. Jedes davon ist ein normaler Dienstag, und jedes reicht, um ein sauberes Ergebnis in ein ernstes zu verwandeln.

Reeve Monitor gibt es für diese Lücke. Es wiederholt alle neun Prüfungen stündlich auf bis zu drei Apps, sieht alle 60 Sekunden nach, ob die App läuft, sagt dir an dem Tag Bescheid, an dem sich ein Ergebnis ändert, statt zu warten, bis du nachsiehst, und schickt einen Monatsbericht in verständlicher Sprache. Es kostet €12 im Monat zum Listenpreis, mit sieben Tagen gratis, bevor abgerechnet wird, und die Preisseite liegt manchmal unter dem Wert hier und nie darüber. Monitor beobachtet und sonst nichts. Backups sind der Care-Tarif darüber, und Care hält eine Kopie einer Supabase-Datenbank und sonst nichts.

Was nichts davon beweist

Dass deine App sicher ist. Neun Prüfungen, die sauber zurückkommen, heißen, dass neun von außen gestellte Fragen an dem Tag sauber zurückkamen, an dem du sie gestellt hast.

Vier Dinge bleiben für jeden Punkt dieser Liste unsichtbar, denn keines davon verlässt je deinen Server. Dein Servercode, samt der Datenbankfunktionen und Edge Functions, die von außen niemand lesen kann. Die Umgebungsvariablen, die du aus dem Browser herausgehalten hast, wo sie genau richtig aufgehoben sind, und weshalb ein Scan auch nicht bestätigen kann, dass sie richtig liegen. Deine Versionsgeschichte, in der ein Schlüssel sitzt, den du im März committet und im April entfernt hast. Und die Logik deiner App selbst, etwa ob ein angemeldeter Nutzer die Bestellung eines anderen öffnen kann, indem er eine Zahl in der Adresse ändert.

Was ein URL-Scan sehen kann und was nicht geht diese Grenze ordentlich durch, samt der drei Werkzeuge, die Verschiedenes lesen, und der Stelle, an der jedes davon blind ist.

Was du jetzt tun kannst

Liegen die Daten deiner App in Supabase, ist die Fassung, die um diesen einen Stack herum geschrieben ist, der Leitfaden für Supabase-Apps. Und wenn du lieber etwas zum Abhaken als zum Lesen willst, ist die 10-Minuten-Sicherheits-Checkliste die interaktive Variante.