Die App läuft. Du hast sie an ein paar Abenden mit Lovable, Bolt oder Claude Code gebaut, sie sieht ordentlich aus, und die ersten Kollegen finden sie gut. Jetzt soll sie raus: an das ganze Team, vielleicht an Kunden, und mit echten Daten statt mit Beispielfirmen.
Genau hier entscheidet sich, ob die Vibe-Coding-App ein Gewinn wird oder ein Risiko. Die KI baut sehr zuverlässig das, was du siehst: Masken, Listen, Knöpfe. Was du nicht siehst, also wer welche Daten lesen darf, wo die Schlüssel liegen und was passiert, wenn etwas schiefgeht, baut sie nur, wenn jemand danach fragt. Beim Thema Vibe Coding Sicherheit geht es deshalb selten um raffinierte Angriffe, sondern fast immer um diese unsichtbaren Stellen. Was Vibe Coding genau ist und wo es endet, steht in Was ist Vibe Coding?
Dieser Beitrag ist eine Prüfliste mit elf Punkten, die du durchgehst, bevor deine App echte Nutzer oder echte Daten bekommt. Zu jedem Punkt steht, warum er zählt und wie du ihn prüfst, auch ohne Entwickler zu sein. Am Ende steht eine Ampel, an der du ablesen kannst, wann du einen Profi draufschauen lassen solltest.
Warum „es funktioniert" noch nicht „es ist sicher" heißt
Eine KI arbeitet auf das hin, was du ihr sagst und was du testest. Du testest, ob die Rechnung erscheint, wenn du auf den Knopf drückst. Du testest nicht, ob ein Fremder dieselbe Rechnung sieht, wenn er die Adresse im Browser ändert. Also fällt es niemandem auf, bis es jemandem auffällt.
Das ist keine Vermutung. Der Sicherheitsanbieter Veracode prüft seit 2025 regelmäßig, wie sicher der Code ist, den Sprachmodelle schreiben. Im Update vom März 2026, mit inzwischen mehr als 150 getesteten Modellen, lag der Anteil sicherer Lösungen bei etwa 55 Prozent, wenn im Auftrag keine ausdrücklichen Sicherheitsvorgaben standen. Syntaktisch korrekt war dagegen über 95 Prozent des Codes. Fast alles läuft also, aber nur gut die Hälfte ist sicher.
Wie das in der Praxis aussieht, zeigt Moltbook, ein soziales Netzwerk für KI-Agenten. Der Gründer schrieb öffentlich, er habe keine einzige Zeile Code selbst geschrieben. Die Sicherheitsfirma Wiz fand Anfang 2026 im ausgelieferten JavaScript einen Datenbankschlüssel, und weil in der Datenbank die Zeilenrechte fehlten, reichte dieser Schlüssel für Lese- und Schreibzugriff auf alles: rund 1,5 Millionen Zugangstokens und 35.000 E-Mail-Adressen. Nach der Meldung war die Lücke in unter drei Stunden geschlossen. Sie wäre auch vorher mit überschaubarem Aufwand zu finden gewesen, und genau dafür ist diese Liste da.
Der Unterschied zwischen Prototyp und belastbarer Anwendung liegt zu einem großen Teil in solchen Prüfungen, mehr dazu in Vibe Coding oder KI-gestützte Softwareentwicklung.
Block 1: Wer kommt an welche Daten?
Wenn du nur Zeit für drei Prüfungen hast, nimm diese.
1. Schlüssel und Geheimnisse gehören nicht ins Frontend
Warum: Alles, was im Browser läuft, kann jeder Besucher lesen, auch wenn es versteckt aussieht. Liegt dort der Schlüssel für die KI-Schnittstelle, den Zahlungsanbieter oder den Mailversand, kann ihn jeder kopieren und auf deine Rechnung nutzen. Dasselbe gilt für Schlüssel im Code-Repository: Einmal eingecheckt, bleiben sie in der Versionsgeschichte, auch wenn du sie später löschst.
So prüfst du es: Öffne die App im Browser, dann die Entwicklerwerkzeuge (meist Taste F12), und such im geladenen Code nach den ersten Zeichen deiner echten Schlüssel aus den Dashboards der Anbieter. Frag zusätzlich die KI, die die App gebaut hat: „Liste alle Schlüssel und Zugangsdaten auf, die diese App nutzt, und sag bei jedem, ob er im Browser landet." GitHub hält bei öffentlichen Repositories viele bekannte Schlüsselformate standardmäßig auf, verlass dich aber nicht allein darauf. War ein Schlüssel schon öffentlich, erzeugst du beim Anbieter einen neuen und löschst den alten.
2. Anmeldung und Berechtigungen: Jeder sieht nur seine Daten
Warum: Ein typischer Fehler in selbst gebauten Apps ist nicht der fehlende Login, sondern das, was danach passiert. Die App zeigt dir brav deine Aufträge, weil die Liste in der Oberfläche gefiltert ist. Die Datenbank dahinter liefert auf direkte Anfrage aber oft auch alle anderen.
So prüfst du es: Leg zwei Testkonten an, A und B. Erstelle mit A ein paar Datensätze, melde dich als B an und versuch, sie zu sehen: über Listen, über die Suche und indem du die Adresse eines Datensatzes von A (etwa /auftrag/123) direkt in den Browser kopierst. Gibt es Rollen wie Mitarbeiter und Admin, prüf zusätzlich, ob ein normales Konto Admin-Seiten öffnen kann und ob ein abgemeldeter Besucher irgendetwas sieht.
3. Datenbankregeln: Zeilenrechte sind kein Detail
Warum: Viele Vibe-Coding-Apps nutzen Supabase als Datenbank. Dort ist der öffentliche Schlüssel (anon key oder publishable key) dafür gedacht, im Browser zu stehen. Das ist aber nur sicher, wenn auf jeder Tabelle Row Level Security eingeschaltet ist, also Zeilenrechte, die festlegen, wer welche Zeilen lesen und ändern darf. Eine Tabelle ohne diese Zeilenrechte kann in der Standardeinstellung jeder mit dem öffentlichen Schlüssel lesen und beschreiben. Der geheime Schlüssel (service_role oder secret key) umgeht alle Zeilenrechte und darf deshalb nie im Browser landen.
Genau das war die Ursache einer viel beachteten Lücke. Der Sicherheitsforscher Matt Palmer fand im März 2025 unter 1.645 untersuchten Lovable-Projekten 170 mit unzureichenden Zeilenrechten. Offen lagen je nach Projekt Namen, E-Mail-Adressen, Telefonnummern, Zahlungsdaten und API-Schlüssel. Die Lücke ist als CVE-2025-48757 dokumentiert.
So prüfst du es: Im Supabase-Dashboard zeigt der Security Advisor typische Lücken wie Tabellen ohne Zeilenrechte. Ob eine Regel zu deinem Geschäft passt, kann er nicht wissen. Das zeigt der Test mit dem zweiten Konto aus Punkt 2, und bei Kundendaten ein Entwickler, der die Regeln einmal liest. Bei Firebase heißen die Entsprechungen Security Rules, die Frage ist dieselbe. Und vergiss die Dateiablage nicht: Hochgeladene PDFs und Bilder brauchen eigene Regeln.
Block 2: Was von außen hereinkommt
4. Eingaben prüfen, und zwar auf dem Server
Warum: KI-generierte Formulare prüfen Eingaben meist nur im Browser, etwa ob ein Feld leer ist oder eine Zahl passt. Diese Prüfung lässt sich umgehen, weil man Anfragen auch ohne Formular direkt an den Server schicken kann. Entscheidend ist, dass der Server selbst prüft. In Veracodes Bericht von 2025 war KI-Code in 86 Prozent der relevanten Fälle nicht gegen Cross-Site-Scripting geschützt, also gegen eingeschleusten Code, der dann im Browser anderer Nutzer läuft.
So prüfst du es: Füttere jedes Formular mit Unsinn: 5.000 Zeichen im Namensfeld, negative Mengen, ein Datum im Jahr 3000, Text wie <b>fett</b>. Erscheint dieser Text irgendwo fett statt als Text, ist das ein Fall für einen Entwickler. Bei Uploads prüfst du, ob sich riesige Dateien oder Programmdateien hochladen lassen. Und hat deine App eine KI-Funktion, die Nutzertexte oder Dokumente liest, gehört Prompt Injection auf die Liste: Text in einem Dokument kann der KI Anweisungen geben.
5. Kosten und Grenzen: Wer darf wie viel verbrauchen?
Warum: Sobald deine App eine KI-Schnittstelle aufruft, kostet jeder Klick Geld. Ein offenes Formular, das ohne Anmeldung eine KI-Antwort erzeugt, ist für Bots eine Einladung, und die Rechnung kommt am Monatsende. Dasselbe gilt für Mail- und SMS-Versand über deine Konten. Wo die Kosten im Normalbetrieb entstehen, steht in KI-Kosten senken.
So prüfst du es: Setz bei jedem Anbieter ein Ausgabenlimit, das du im schlimmsten Fall verschmerzen kannst. Bei Anthropic geht das in der Console unterhalb der Obergrenze deiner Stufe, auch getrennt je Workspace, bei OpenAI gibt es harte Limits für Organisation und Projekt, nach denen Anfragen abgelehnt werden (Stand: September 2026). Dann prüf die App selbst: Gibt es ein Limit pro Nutzer und Tag, ist die Registrierung gegen Bots geschützt (Supabase bietet dafür etwa ein CAPTCHA an), und was sieht ein Nutzer, wenn das Limit erreicht ist: eine verständliche Meldung oder eine weiße Seite?
Block 3: Wenn etwas schiefgeht
6. Sicherungen: einmal wirklich zurückspielen
Warum: Eine Sicherung, die nie zurückgespielt wurde, ist eine Hoffnung. Im Juli 2025 löschte der Replit-Agent während eines öffentlichen Experiments von SaaStr-Gründer Jason Lemkin die Produktionsdatenbank, obwohl ausdrücklich ein Änderungsstopp galt, und behauptete danach, eine Wiederherstellung sei unmöglich. Sie war möglich, das Zurückrollen funktionierte. Auch Supabase sichert nicht in jedem Tarif: Auf dem kostenlosen Plan gibt es keine automatischen täglichen Sicherungen, und hochgeladene Dateien sind in den Datenbanksicherungen grundsätzlich nicht enthalten.
So prüfst du es: Finde heraus, wo die Sicherungen liegen, wie oft sie laufen und wie lange sie aufbewahrt werden. Dann spiel eine davon in eine getrennte Testumgebung zurück und prüf, ob die App damit startet und die Daten vollständig sind. Miss dabei die Zeit: So lange steht dein Betrieb im Ernstfall.
7. Fehlerüberwachung: Du erfährst es vor deinen Kunden
Warum: Ohne Überwachung erfährst du von Fehlern, wenn ein Kunde anruft, oder gar nicht, weil er einfach geht. Viele selbst gebaute Apps zeigen Fehler nur im Browser des Nutzers, wo niemand hinschaut.
So prüfst du es: Richte einen Dienst zur Fehlerüberwachung ein und dazu eine einfache Erreichbarkeitsprüfung, die dich benachrichtigt, wenn die App nicht antwortet. Dann lös absichtlich einen Fehler aus und schau, ob und bei wem die Meldung ankommt. Landet sie in einem Postfach, das niemand liest, ist der Punkt nicht erledigt.
8. Testdaten und echte Daten trennen
Warum: Solange du baust, darf alles kaputtgehen. Sobald echte Kundendaten drin sind, nicht mehr. Wenn der bauende Agent und die echten Nutzer auf dieselbe Datenbank zugreifen, reicht ein missverstandener Satz im Chat, wie der Fall Replit zeigt. Replit hat danach angekündigt, Entwicklungs- und Produktionsdatenbank automatisch zu trennen, und genau diese Trennung brauchst du auch.
So prüfst du es: Frag konkret nach: Mit welcher Datenbank ist die Vorschau verbunden, mit welcher die Live-Version, und hat der Agent Zugriff auf die Live-Datenbank? Das gilt auch, wenn du wie in Claude Code auf einem eigenen Server arbeitest: Der Agent bekommt die Zugänge zur Testumgebung, nicht zu den echten Daten. Wie viel ein Agent überhaupt selbst entscheiden sollte, steht in Agentic AI: wie viel Autonomie. Vor dem Start räumst du Testkonten aus der Live-Umgebung, und echte Kundendaten kopierst du nie als Beispiel in den KI-Chat.
Block 4: Damit die App in einem Jahr noch läuft
9. Abhängigkeiten und Updates
Warum: Jede App besteht zum größten Teil aus fremden Paketen, und in diesen werden laufend Lücken gefunden. Dazu kommt ein Risiko, das es erst mit KI gibt: Sprachmodelle erfinden gelegentlich Paketnamen. In einer Studie, die 2025 auf der Fachkonferenz USENIX Security erschien, waren im Schnitt knapp 20 Prozent der vorgeschlagenen Pakete erfunden, bei kommerziellen Modellen rund 5 Prozent. Angreifer können solche Namen registrieren und Schadcode hineinlegen.
So prüfst du es: Lass dir die Liste der verwendeten Pakete zeigen (bei JavaScript-Projekten die Datei package.json) und frag bei unbekannten Namen nach, ob es sie wirklich gibt und wer sie pflegt. Schalte im Repository Warnungen für bekannte Sicherheitslücken ein, bei GitHub heißen sie Dependabot alerts. Und leg fest, wer diese Warnungen liest und Updates einspielt, monatlich statt irgendwann.
10. Code-Export und Versionskontrolle
Warum: Solange der Code nur in der Plattform lebt, hängt deine App an deren Preisen, Grenzen und Fortbestand. Mit Versionskontrolle kannst du außerdem jede Änderung nachvollziehen und zurücknehmen, wenn die KI beim Reparieren etwas anderes kaputt macht. Warum das mit Agenten wichtiger wird als früher, steht in Git erklärt.
So prüfst du es: Liegt der Code in einem Git-Repository, das deiner Firma gehört, also auf eurem Konto und nicht auf dem eines Freelancers? Lovable etwa synchronisiert Projekte auf Wunsch mit GitHub. Der eigentliche Test ist aber, ob sich das Projekt außerhalb der Plattform starten lässt. Und Code ist nicht dasselbe wie Daten: Prüf getrennt, wie du an einen vollständigen Export deiner Datenbank kommst. Mehr zu diesem Thema in Wenn das Modell abgeschaltet wird.
11. Wer die App betreut
Warum: Die meisten Vibe-Coding-Apps haben jemanden, der sie gebaut hat, aber niemanden, der sie betreut. Ist diese Person im Urlaub oder nicht mehr im Haus, weiß niemand, wo die Zugänge liegen, und die App läuft weiter, bis sie es nicht mehr tut.
So prüfst du es: Schreib auf einer Seite auf, wer zuständig ist und wer vertritt, wo die Zugänge liegen, wer Fehlermeldungen und Sicherheitswarnungen bekommt und wie oft Updates eingespielt werden. Die Konten bei Plattform, Datenbank und KI-Anbieter sollten mindestens zwei Administratoren mit Zwei-Faktor-Anmeldung haben, beides empfiehlt etwa Supabase in seiner Checkliste für den Produktivbetrieb. Kann im Haus niemand diese Rolle übernehmen, ist das ein Grund, die Betreuung abzugeben.
Die Prüfliste zum Abhaken
Ein Punkt gilt erst als erledigt, wenn du ihn ausprobiert hast, nicht wenn die KI sagt, er sei erledigt.
| Prüfpunkt | Bestanden, wenn |
|---|---|
| 1. Schlüssel und Geheimnisse | Kein geheimer Schlüssel im Browsercode oder im Repository, alte Schlüssel ausgetauscht |
| 2. Anmeldung und Berechtigungen | Testkonto B sieht keinen einzigen Datensatz von Testkonto A, auch nicht über die direkte Adresse |
| 3. Datenbankregeln | Zeilenrechte auf jeder Tabelle und jeder Dateiablage, Regeln passen zum tatsächlichen Zugriff |
| 4. Eingaben | Unsinnige Eingaben werden vom Server abgelehnt, eingegebener Text erscheint immer als Text |
| 5. Kosten und Grenzen | Ausgabenlimit bei jedem Anbieter, Limit pro Nutzer, Schutz gegen Bots |
| 6. Sicherungen | Eine Sicherung wurde zurückgespielt, die App lief damit, die Dauer ist bekannt |
| 7. Fehlerüberwachung | Ein absichtlicher Fehler kam bei einer Person an, die ihn liest |
| 8. Testdaten und echte Daten | Zwei getrennte Umgebungen, der Agent hat keinen Zugriff auf die Live-Daten |
| 9. Abhängigkeiten | Alle Pakete existieren und werden gepflegt, Warnungen sind eingeschaltet |
| 10. Code-Export | Code im eigenen Repository, Projekt startet außerhalb der Plattform, Datenexport geklärt |
| 11. Betreuung | Zuständige Person und Vertretung benannt, zwei Admins mit Zwei-Faktor-Anmeldung |
Wann du einen Profi draufschauen lässt
Nicht jede App braucht eine professionelle Prüfung. Die Ampel richtet sich danach, wer die App nutzt und welche Daten drin sind.
| Ampel | Typische Situation | Empfehlung |
|---|---|---|
| Grün | Nur du oder wenige Kollegen nutzen die App, keine Kundendaten, keine Zahlungen, keine kostenpflichtige KI-Schnittstelle | Prüfliste selbst durchgehen reicht |
| Gelb | Das ganze Team arbeitet damit, interne Firmendaten, Login, eine KI-Schnittstelle mit laufenden Kosten | Prüfliste selbst durchgehen, dazu ein Entwickler, der die Punkte 1 bis 3 und 6 einmal gegenprüft |
| Rot | Kunden oder Externe melden sich an, Kundendaten, Zahlungen, Dokumenten-Uploads, Anbindung an ERP, CRM oder Buchhaltung, die App schreibt in andere Systeme | Vor dem Livegang professionell prüfen lassen, oft verbunden mit der Frage, ob die App gehärtet oder sauber neu gebaut wird |
Landest du bei Rot, war die Arbeit trotzdem nicht umsonst. Ein funktionierender Prototyp ist die beste Beschreibung dessen, was du brauchst, besser als jedes Lastenheft. Ich würde ihn als Ausgangspunkt nehmen: Code und Datenbank ansehen und dann ehrlich entscheiden, ob sich Härten lohnt oder ein sauberer Neubau schneller ans Ziel kommt. Wie ich dabei vorgehe, steht auf der Seite zur Softwareentwicklung.
Häufige Fragen
Ist Vibe Coding sicher?
Vibe Coding ist so sicher wie die Prüfung danach. Sicherheit entsteht nur dort, wo jemand ausdrücklich danach fragt und das Ergebnis testet. Für Prototypen ohne sensible Daten ist das Risiko überschaubar, für Apps mit Kundendaten brauchst du die Prüfliste und bei Rot einen zweiten Blick.
Ist der Supabase-Anon-Key im Frontend ein Sicherheitsproblem?
Nein, solange auf jeder Tabelle Zeilenrechte eingeschaltet sind und die Regeln stimmen. Der öffentliche Schlüssel ist dafür gedacht, im Browser zu stehen. Zum Problem wird er erst, wenn Tabellen ohne Zeilenrechte existieren, wie bei Moltbook. Der geheime Schlüssel (service_role oder secret key) dagegen gehört nie in den Browser.
Kann die KI ihre eigene App auf Sicherheit prüfen?
Als erster Durchgang ja. Gib ihr diese Prüfliste und lass sie jeden Punkt einzeln durchgehen, das findet einen Teil der Lücken. Den Praxistest ersetzt es nicht: Zwei Testkonten, eine zurückgespielte Sicherung und ein absichtlicher Fehler zeigen, was wirklich passiert.
Reicht der Sicherheitsscan der Plattform?
Er ist ein guter Anfang und findet typische Lücken wie Tabellen ohne Zeilenrechte. Ob eine vorhandene Regel zu deinem Geschäft passt, kann ein Scanner aber nicht wissen. Matt Palmer kritisierte 2025 am damals neuen Scanner von Lovable genau das: Er prüfe, ob überhaupt eine Regel existiert, nicht ob sie richtig ist.
Brauche ich die Prüfliste auch für ein internes Tool?
In abgespeckter Form ja. Auch intern sollen nicht alle alles sehen, etwa Gehälter oder Kundenkonditionen, und Sicherungen, Betreuung und Ausgabenlimits brauchst du unabhängig davon, wer die App nutzt. Wenn das Tool über das Internet erreichbar ist, gilt ohnehin die volle Liste.
Fazit
Die meisten Sicherheitsprobleme in Vibe-Coding-Apps sind keine Geheimwissenschaft. Es sind fehlende Zeilenrechte, Schlüssel am falschen Ort, ungetestete Sicherungen und niemand, der zuständig ist. Tückisch ist nur, dass man keinem dieser Fehler ansieht, dass er da ist.
Deshalb gilt: erst prüfen, dann echte Daten. Die meisten der elf Punkte kannst du ohne Programmierkenntnisse selbst testen, und jeder davon ist fast immer billiger als die Lücke, die er verhindert. Was bei Rot landet, gehört vor dem Livegang auf den Tisch von jemandem, der so etwas regelmäßig baut.
Wenn du erst einmal sehen willst, wo KI in deinem Betrieb den größten Hebel hat, mach den KI-Potenzial-Check. Steht deine App schon und du willst wissen, ob sie reif für echte Nutzer ist, schau dir meine KI-gestützte Softwareentwicklung an oder buch direkt eine kostenlose Prozessanalyse, in der wir gemeinsam draufschauen.