Vibe Coding ist nicht von Haus aus sicher, aber auch nicht von Natur aus unsicher: Eine KI-generierte Web-App ist so sicher wie die Prüfungen, die jemand an ihr durchgeführt hat. Dieselben wenigen Fehler tauchen in Apps aus KI-Baukästen immer wieder auf: Daten, die jeder lesen kann, geheime Schlüssel im Browser, Regeln, die nur in der Oberfläche gelten. Jeden davon kann ein Nicht-Entwickler in wenigen Minuten testen, und für jeden gibt es einen Folge-Prompt, der ihn behebt.
Diese Checkliste richtet sich an Gründer, Freelancer und kleine Teams, die dem ersten echten Nutzer Zugang zu einer mit einem KI-Baukasten gebauten App geben wollen. Wenn Sie die Methode noch nicht kennen, beginnen Sie mit unserem Vibe-Coding-Leitfaden. Wenn Ihre App Supabase nutzt, finden Sie die Details zur Datenbankseite in unserem Leitfaden zu Supabase Row Level Security.
Warum KI-Apps immer auf dieselbe Weise scheitern
Ein KI-Baukasten optimiert auf eine App, die auf dem Bildschirm funktioniert, und ein funktionierender Bildschirm sagt nichts darüber, wer sonst noch an die Daten dahinter kommt. Wenn Sie „ein Dashboard, in dem jeder Kunde seine Rechnungen sieht“ verlangen, baut das Modell zuerst den Bildschirm. Ob die Datenbank sich weigert, die Rechnungen anderer Kunden herauszugeben, ist eine eigene Aufgabe, und sie wird nur erledigt, wenn der Prompt oder die Standardeinstellungen des Baukastens es verlangen.
Ein öffentliches Beispiel zeigt die Form des Problems. 2025 wurde ein Schwachstelleneintrag (CVE-2025-48757) veröffentlicht, der unzureichende Row-Level-Security-Policies in mit Lovable generierten Websites bis zum 15.04.2025 beschreibt, die es nicht angemeldeten Besuchern erlaubten, Tabellen zu lesen oder zu beschreiben. Der Eintrag der National Vulnerability Database vermerkt auch, dass der Anbieter den Befund bestreitet und festhält, jeder Kunde sei selbst für den Schutz seiner Anwendungsdaten verantwortlich. Beide Aussagen führen zum selben praktischen Schluss: Wer die App veröffentlicht, muss ihre Zugriffsregeln prüfen, egal welches Tool sie geschrieben hat.
Die sieben Fehler im Überblick
Die meisten dieser Fehler lassen sich den OWASP Top 10 zuordnen, der Referenzliste der Risiken für Webanwendungen, in der Ausgabe 2025. Die Zuordnung unten verwendet die Kategorienamen dieser Liste.
| Fehler | Was ein Angreifer tut | OWASP-Kategorie 2025 | Ihr 10-Minuten-Test |
|---|---|---|---|
| 1. Fehlende Row Level Security | Liest oder ändert jede Tabelle über die öffentliche API | A01 Broken Access Control | Zwei Konten, vergleichen, was jedes sieht |
| 2. Geheime Schlüssel im Frontend | Kopiert den Schlüssel aus dem Browser und gibt Ihr Geld aus | A02 Security Misconfiguration | Netzwerk-Tab und Seitenquelltext |
| 3. Regeln nur in der Oberfläche | Ruft die API direkt auf und umgeht den versteckten Button | A01 Broken Access Control | Eine Anfrage mit der falschen Rolle wiederholen |
| 4. Admin-Seiten per URL erreichbar | Tippt /admin in die Adressleiste | A01 Broken Access Control | Admin-URLs abgemeldet und als normaler Nutzer öffnen |
| 5. Datei-Uploads ohne Prüfung | Lädt riesige, falsche oder öffentliche Dateien hoch | A06 Insecure Design | Eine falsche Datei hochladen, ihren Link abgemeldet öffnen |
| 6. Veraltete Abhängigkeiten | Nutzt eine bekannte Schwachstelle in einem alten Paket | A03 Software Supply Chain Failures | Den Audit-Befehl für Pakete ausführen |
| 7. Keine Rate Limits | Überflutet die Registrierung oder leert Ihre KI-Credits | A06 Insecure Design | Eine Anfrage 50 Mal wiederholen und beobachten, was passiert |
1. Fehlende Row Level Security
Bei einem Supabase-Backend spricht der Browser die Datenbank über eine öffentliche API an, sodass zwischen einem Besucher und Ihren Tabellen nur die Row Level Security (RLS) steht: Regeln, die an jeder Tabelle festlegen, welche Zeilen ein Nutzer lesen oder schreiben darf. Eine Tabelle ohne aktivierte RLS kann jeder lesen, der den öffentlichen Schlüssel hat, und dieser Schlüssel liegt konstruktionsbedingt im Browser. Supabase erklärt den Mechanismus in seiner Dokumentation zu Row Level Security.
Der Test dauert fünf Minuten. Legen Sie zwei Konten, A und B, mit verschiedenen E-Mail-Adressen an. Erstellen Sie als A einen Datensatz (eine Rechnung, eine Notiz, ein Projekt). Melden Sie sich ab, als B wieder an und suchen Sie den Datensatz von A in jeder Liste und Suche. Öffnen Sie dann die Devtools des Browsers, wechseln Sie in den Reiter Netzwerk, laden Sie die Seite neu, klicken Sie eine Anfrage an die Datenbank an und lesen Sie die Antwort: Sie darf nur die Zeilen von B enthalten. Melden Sie sich zuletzt ab und laden Sie dieselbe Seite neu: Die Anfragen sollten nichts oder einen Fehler zurückgeben.
Folge-Prompt: „Liste jede Tabelle der Datenbank auf, mit der Angabe, ob Row Level Security aktiviert ist und welche Policies gelten. Aktiviere RLS auf jeder Tabelle, die keine hat, und schreibe Policies, sodass ein Nutzer nur Zeilen auswählen, einfügen, ändern und löschen kann, bei denen user_id seiner eigenen ID entspricht. Zeige mir die Policies und erkläre jede Tabelle, die du absichtlich öffentlich gelassen hast.“
2. Geheime Schlüssel im Frontend
Alles, was an den Browser ausgeliefert wird, ist öffentlich, auch jeder Schlüssel, den Sie im Seitenquelltext finden. Manche Schlüssel sind dafür gedacht, öffentlich zu sein (der öffentliche Schlüssel von Supabase, geschützt durch RLS). Andere nicht: geheime Zahlungsschlüssel, Schlüssel von KI-Anbietern, Schlüssel von E-Mail-Diensten, der Service-Role-Schlüssel der Datenbank. Ein Besucher, der einen davon kopiert, kann E-Mails in Ihrem Namen versenden oder KI-Anfragen auf Ihre Rechnung ausführen.
Zum Testen öffnen Sie die veröffentlichte App, öffnen die Devtools, gehen in die Reiter Netzwerk und Quellen und suchen nach den ersten Zeichen jedes Geheimnisses, das Sie verwenden (zum Beispiel „sk_“ für einen Zahlungsschlüssel), und nach dem Namen jedes Anbieters. Durchsuchen Sie auch den Code des Projekts und sein GitHub-Repository, falls Sie exportieren. Ein Geheimnis in einem öffentlichen Repository gilt als kompromittiert, auch wenn Sie es danach löschen.
Folge-Prompt: „Durchsuche das ganze Projekt nach API-Schlüsseln, Tokens und Geheimnissen im Client-Code. Verlege jeden Aufruf, der ein Geheimnis braucht, in eine serverseitige Edge Function, lies den Schlüssel aus Umgebungsvariablen und verwende den Service-Role-Schlüssel nie im Browser. Liste auf, was du verschoben hast.“ Wurde ein Geheimnis offengelegt, rotieren Sie es beim Anbieter: Den Code zu löschen, hebt den Schlüssel nicht auf.
3. Berechtigungen nur in der Oberfläche geprüft
Einen Button auszublenden ist eine Gestaltungsentscheidung, keine Berechtigung. Ist der Löschen-Button für die Rolle „Betrachter“ ausgeblendet, die Datenbank nimmt die Löschanfrage aber trotzdem an, kann jeder Betrachter mit Devtools sie abschicken. Regeln müssen dort durchgesetzt werden, wo die Daten liegen, und die Oberfläche spiegelt sie nur wider.
Zum Testen melden Sie sich mit der niedrigsten Rolle an, führen eine erlaubte Aktion wie Lesen aus und kopieren im Netzwerk-Tab diese Anfrage (Rechtsklick, „Als fetch kopieren“). Ändern Sie sie in etwas Verbotenes, etwa die ID eines anderen Datensatzes oder ein Rollenfeld, und führen Sie sie in der Konsole aus. Gelingt das, lebt die Regel nur in der Oberfläche. Prüfen Sie auch, dass ein Nutzer sein eigenes Rollen- oder Tarif-Feld nicht ändern kann.
Folge-Prompt: „Liste für jede Rolle auf, welche Aktionen sie auf jeder Tabelle ausführen darf. Setze sie mit Datenbank-Policies durch, nicht nur in der Oberfläche. Verhindere, dass Nutzer ihre eigenen Spalten role, plan oder user_id ändern.“
4. Admin-Seiten per URL erreichbar
Eine Admin-Seite, die im Menü einfach nicht verlinkt ist, ist für jeden erreichbar, der die Adresse errät. Die Seite muss die Rolle prüfen, bevor sie irgendetwas anzeigt, und die Daten dahinter müssen durch die Policies aus Punkt 1 geschützt sein.
Zum Testen listen Sie Ihre Admin-Routen auf (/admin, /settings/users, /dashboard/all). Öffnen Sie jede in einem privaten Fenster abgemeldet und dann angemeldet als normaler Nutzer. Sie sollten auf einer Login-Seite oder einer Seite „Zugriff verweigert“ landen, und der Netzwerk-Tab sollte in keiner Antwort Admin-Daten zeigen.
Folge-Prompt: „Schütze jede Admin-Route, sodass nur Nutzer mit der Rolle admin sie öffnen können, leite alle anderen um und stelle sicher, dass auch die Datenabfragen dieser Seiten für Nicht-Admins fehlschlagen.“
5. Datei-Uploads ohne Prüfung
Ein Upload-Feld, das jede Datei in beliebiger Größe in einen öffentlichen Ordner annimmt, lässt Fremde Inhalte auf Ihrer Domain hosten und Ihren Speicher füllen. Private Dokumente (Verträge, Lebensläufe, Rechnungen) dürfen nicht über einen erratbaren Link lesbar sein.
Zum Testen laden Sie eine Datei vom falschen Typ hoch (eine ausführbare Datei, umbenannt in .jpg) und eine sehr große Datei. Kopieren Sie dann den Link eines hochgeladenen privaten Dokuments und öffnen Sie ihn in einem privaten Fenster. Öffnet er sich, ist der Bucket öffentlich.
Folge-Prompt: „Beschränke Uploads auf diese Dateitypen: [Liste] und eine Höchstgröße von [x MB], geprüft beim Upload. Mache den Bucket privat, füge Storage-Policies hinzu, sodass ein Nutzer nur seine eigenen Dateien lesen kann, und liefere Dateien über signierte Links aus, die ablaufen.“
6. Veraltete Abhängigkeiten
Eine App besteht aus Hunderten von Open-Source-Paketen, und ein Paket mit bekannter Schwachstelle ist ein fertiger Einstieg. OWASP fasst das unter Software Supply Chain Failures zusammen. Die KI kann außerdem eine alte Version eines Pakets wählen, die sie aus älteren Beispielen gelernt hat.
Der Test ist ein Befehl im exportierten Projekt: „npm audit“ listet bekannte Schwachstellen in den installierten Paketen auf. Können Sie ihn nicht ausführen, bitten Sie die KI um eine gleichwertige Prüfung. Planen Sie sie vor jedem größeren Release erneut ein.
Folge-Prompt: „Prüfe die Abhängigkeiten auf bekannte Schwachstellen und veraltete Hauptversionen. Aktualisiere die, für die es einen Fix gibt, vermeide Breaking Changes und liste auf, was du nicht aktualisieren konntest und warum. Entferne Pakete, die die App nicht nutzt.“
7. Keine Rate Limits bei Registrierung und KI-Endpunkten
Ohne Limits kann ein Skript Tausende Fake-Konten anlegen oder Ihren KI-Endpunkt aufrufen, bis nicht Ihre Nutzerzahl, sondern die Rechnung Ihres Anbieters wächst. Zwei Stellen sind am wichtigsten: die Registrierung (und das Zurücksetzen des Passworts, das E-Mails versendet) und jede Funktion, die eine kostenpflichtige API aufruft.
Zum Testen senden Sie dieselbe Registrierungs- oder KI-Anfrage viele Male hintereinander aus den Devtools oder einem einfachen Skript und beobachten, ob etwas sie bremst oder blockiert. Prüfen Sie auch, dass KI-Endpunkte einen angemeldeten Nutzer verlangen und dass ein Nutzer keinen Prompt von 10 MB senden kann.
Folge-Prompt: „Verlange Login bei jeder Edge Function, die eine kostenpflichtige API aufruft, begrenze jeden Nutzer auf [n] Aufrufe pro Stunde, begrenze die Eingabegröße und gib bei Erreichen des Limits einen klaren Fehler zurück. Aktiviere E-Mail-Bestätigung und ein Captcha bei der Registrierung.“
Personenbezogene Daten und DSGVO
Wenn Ihre Nutzer in Europa sitzen, enthält die App personenbezogene Daten, und Sie sind dafür verantwortlich, egal mit welchem Tool die App gebaut wurde. Die oben genannten Sicherheitsfehler sind zugleich der übliche Weg, auf dem personenbezogene Daten abfließen. Prüfen Sie darüber hinaus die Grundlagen: eine Datenschutzerklärung, die zu dem passt, was die App tatsächlich erhebt, eine Möglichkeit, das Konto und die Daten eines Nutzers zu löschen, und keine personenbezogenen Daten in Logs oder Analytics, die Sie nicht senden wollten. Unser Beitrag zu DSGVO und KI-No-Code-Apps behandelt die rechtliche Seite ausführlicher.
Folge-Prompt: „Füge eine Funktion zum Löschen des Kontos hinzu, die die Zeilen und Dateien des Nutzers entfernt, liste jedes gespeicherte personenbezogene Datenfeld mit dem Grund auf und stelle sicher, dass keine personenbezogenen Daten in Logs geschrieben werden.“
Was Cadrant standardmäßig tut und was nicht
Cadrant, unser Baukasten, erzeugt React-Apps mit einem Supabase-Backend in Ihrem eigenen Supabase-Konto. Standardmäßig schreibt die KI die Datenbankmigrationen mit Row-Level-Security-Policies auf Tabellen pro Nutzer, einschließlich Storage-Policies, und sie kann das aktuelle Schema und die Policies einsehen, bevor sie etwas ändert. Geheime Schlüssel kommen nicht in den Client-Code: Integrationen wie Stripe, OpenAI oder E-Mail-Anbieter laufen über Supabase Edge Functions, mit Geheimnissen als Umgebungsvariablen. Unsere Dokumentation beschreibt das auf den Seiten zu Edge Functions und Umgebungsvariablen.
Standardeinstellungen verringern die Zahl der Fehler; den Test ersetzen sie nicht. Ein Prompt kann trotzdem eine öffentliche Tabelle verlangen, ein Modell kann bei einer später hinzugefügten Tabelle eine Policy übersehen, und kein Baukasten prüft Ihre Geschäftsregeln für Sie. Führen Sie den Zwei-Konten-Test nach jeder größeren Änderung durch, egal welches Tool Sie nutzen.
Eine Checkliste vor dem Launch
Verarbeitet die App Zahlungen, Gesundheitsdaten oder andere regulierte Informationen, lohnt sich eine einmalige Prüfung durch einen Sicherheitsexperten: Diese Checkliste fängt die häufigen Fehler ab, nicht jeden Fehler. Zur Bauseite lesen Sie unsere Seite zum KI-App-Baukasten.