Ist Vibe Coding sicher? Die echten Risiken und was du vor der Veröffentlichung prüfen solltest
Vibe Coding ist sicher für persönliche Tools und Prototypen, und es kann auch für echte Apps mit echten Nutzern sicher sein – aber nur, wenn du die Prüfungen ergänzt, die „einfach beschreiben und schauen, ob es funktioniert“ auslässt. Die gefährlichen Probleme sieht man auf dem Bildschirm nicht: Nutzer, die die Daten anderer öffnen können, geheime Schlüssel, die im Browser liegen, und öffentliche Formulare ohne Limits. Dieser Leitfaden erklärt die Risiken, die tatsächlich Ärger verursachen, wie du mit Geheimnissen umgehst, wie viel Prüfung du brauchst, und einen 30-Minuten-Check, den du vor der Veröffentlichung durchführen solltest.
Die vollständige technische Liste findest du in unserer Sicherheits-Checkliste für KI-gebaute Apps. Diese Seite ist die kürzere, praxisnahe Version für Menschen, die keinen Code lesen.
Warum Vibe Coding eigene Risiken hat
Wenn du Vibe Coding betreibst, beurteilst du die App, indem du sie benutzt. Das fängt kaputte Buttons und hässliche Layouts ab. Es fängt aber keine Probleme ab, die nur auftauchen, wenn jemand die App anders nutzt als du: ein Fremder, ein Bot, ein neugieriger Nutzer, der eine Web-Adresse verändert.
KI-Modelle schreiben plausiblen Code, und das meiste davon ist in Ordnung. Sie optimieren aber auf das, was du verlangt hast – „zeig mir im Dashboard meine Projekte“ – und fügen womöglich den Schutz nicht hinzu, den du nicht erwähnt hast: „und nur meine, nicht die anderer“. Die Lösung ist nicht, mit Vibe Coding aufzuhören. Du musst die Schutzmaßnahmen ausdrücklich verlangen und dann testen.
Wie riskant ist deine App? Eine kurze Einschätzung
| Deine App | Risiko | Was du brauchst |
|---|---|---|
| Ein persönliches Tool, das nur du nutzt, ohne sensible Daten | Niedrig | Schlüssel aus dem Code heraushalten. Mehr ist meist nicht nötig. |
| Eine öffentliche Website oder Landing Page mit Formular | Niedrig bis mittel | Formular-Limits, Bot-Schutz, keine Geheimnisse auf der Seite |
| Eine App, in der sich Menschen anmelden und ihre eigenen Daten speichern | Mittel | Alles auf dieser Seite |
| Zahlungen, Gesundheits-, Finanz-, Kinder- oder Ausweisdaten | Hoch | Alles auf dieser Seite, plus eine Entwicklerprüfung |
Sei ehrlich, in welcher Zeile du stehst. Viele Apps starten in der ersten Zeile und rutschen in die dritte, ohne dass jemand das entschieden hat.
Die Risiken, die tatsächlich Ärger machen
1. Nutzer können die Daten der anderen sehen
Das ist das häufigste ernste Problem bei KI-gebauten Apps. Die Seite zeigt jedem Nutzer nur seine Datensätze, also sieht sie korrekt aus. Doch der Server liefert jeden Datensatz aus, wenn jemand die ID in der Adresszeile oder in einer Anfrage ändert. Da du immer mit deinem eigenen Konto testest, siehst du das nie.
So prüfst du es: Lege zwei Konten an. Melde dich als Nutzer A an, öffne einen Datensatz von A und merke dir die Adresse. Melde dich als Nutzer B in einem privaten Fenster an und füge diese Adresse ein. Du solltest „nicht gefunden“ sehen, niemals die Daten von A.
Prompt:
Prüfe jeden Server-Endpunkt, der Nutzerdaten liest, ändert oder löscht. Jeder muss bestätigen, dass der angemeldete Nutzer genau auf diesen Datensatz zugreifen darf. Liste die Endpunkte auf, beschreibe, wie jeder prüft, und behebe alle, die das nicht tun.
2. Geheimnisse am falschen Ort
Ein Geheimnis ist alles, was Zugriff gewährt: ein API-Schlüssel für einen KI- oder E-Mail-Dienst, ein Datenbank-Passwort, der geheime Schlüssel eines Zahlungsanbieters. Liegt er in Code, der im Browser läuft, kann jeder die Entwicklerwerkzeuge öffnen und ihn kopieren. Wird er in einem öffentlichen Repository committet, finden Bots ihn innerhalb von Stunden.
So prüfst du es: Frag die KI.
Liste jeden API-Schlüssel, jedes Token und jedes Passwort auf, die diese App verwendet. Sag für jedes, wo es gespeichert ist und ob es jemals an den Browser gesendet wird. Verschiebe alle, die im Code oder im Frontend liegen, in serverseitige Geheimnisse.
3. Öffentliche Formulare und Endpunkte ohne Limits
Kontaktformulare, Anmeldungen und KI-Funktionen werden von Bots gefunden. Ohne Limits bekommst du Spam, gefälschte Konten oder eine hohe Rechnung, weil eine KI-Schnittstelle tausendfach aufgerufen wird.
Prompt:
Füge Rate-Limits zur Anmeldung, zum Login, zum Kontaktformular und zu jedem Endpunkt hinzu, der einen KI-Dienst aufruft. Füge bei öffentlichen Formularen ein Honeypot-Feld hinzu. Sag mir, welche Limits du gewählt hast.
4. Dem Browser vertrauen
Alles, was der Browser entscheidet, kann der Nutzer verändern: Preise, Rabatte, Quiz-Antworten, „ist Admin“-Markierungen. Regeln, die zählen, müssen auf dem Server durchgesetzt werden.
Prompt:
Finde jede Stelle, an der der Browser etwas entscheidet, was der Server entscheiden sollte: Preise, Summen, Berechtigungen, Rollen, Punktestände. Verschiebe diese Prüfungen auf den Server.
5. Kein Weg zurück
Eine fehlerhafte Änderung oder ein böswilliger Akteur kann Daten löschen. Ohne Backup und ohne Möglichkeit zum Zurückrollen wird ein kleiner Fehler dauerhaft. Sorge dafür, dass dein Tool Checkpoints für den Code und Backups für die Datenbank hat. Siehe So sicherst du die Datenbank deiner App.
Geheimnisse richtig behandeln
Geheimnisse richten mehr vermeidbaren Schaden an als alles andere, deshalb hier die Regeln auf einen Blick:
- Füge nie einen echten Schlüssel in den Chat ein. Chats werden gespeichert, geteilt und als Screenshot festgehalten. Lege Schlüssel stattdessen in den Geheimnissen oder Umgebungsvariablen deines Tools ab. (Was Umgebungsvariablen und Geheimnisse sind.)
- Rufe kostenpflichtige Dienste vom Server aus auf. Der Browser fragt deinen Server; dein Server ruft mit dem Schlüssel den KI- oder Zahlungsdienst auf.
- Verwende getrennte Schlüssel für Test und Live-Betrieb, damit ein geleakter Testschlüssel kein echtes Geld berühren kann.
- Setze Ausgabenlimits in den Dashboards der KI- und E-Mail-Anbieter.
- Tausche einen Schlüssel sofort aus, wenn du glaubst, dass er geleakt ist. Erstelle einen neuen, aktualisiere das Geheimnis und lösche dann den alten.
Bei Mythex liegen Geheimnisse in den Projekteinstellungen außerhalb des Codes, und der Agent kann sie nutzen, ohne dass die Werte im Chat erscheinen. Unser Leitfaden So bewahrst du API-Schlüssel sicher auf behandelt weitere Anbieter.
Wie viel Code-Prüfung brauchst du?
Bei Vibe Coding liest du nicht jede Zeile. Das musst du auch nicht. Bei manchen Zeilen sollte aber jemand draufschauen.
- Persönliche Tools: nichts über die Prüfungen hier hinaus.
- Apps mit Nutzerkonten: prüfe, wie Login und Datenzugriff funktionieren. Du kannst die KI bitten, es in einfachen Worten zu erklären, und prüfen, ob die Erklärung zu deinen Erwartungen passt.
- Apps mit Zahlungen oder sensiblen Daten: Lass eine Entwicklerin oder einen Entwickler Authentifizierung, Berechtigungen, Zahlungsabwicklung und alles, was persönliche Daten speichert, ansehen. Das sind ein paar Stunden Arbeit, kein Neubau.
Ein nützlicher Prompt, auch ohne Entwickler:
Erkläre in einfachen Worten, wie diese App entscheidet, wer ein Nutzer ist und was er sehen darf. Zeige auf die Dateien. Liste danach alles auf, was ein Sicherheitsprüfer sich ansehen sollte.
Unser Leitfaden So prüfst du KI-generierten Code erklärt, worauf Prüfer achten, und du kannst ihn an die Person weitergeben, die die Prüfung macht. Wenn dein Tool den Export des Codes oder die Synchronisierung mit GitHub erlaubt, ist die Prüfung einfach zu organisieren; bei Mythex gehören beide Funktionen zu Pro.
Der 30-Minuten-Check vor der Veröffentlichung
Führe ihn durch, bevor du den Link mit jemandem außerhalb deines Kreises teilst.
Zugriff (10 Minuten)
- Zwei Konten, zwei Browser: Kann B die Datensätze von A über die URL öffnen? Das sollte nicht gehen.
- Melde dich ab und rufe die Adresse jeder Seite direkt auf. Private Seiten sollten dich zum Login schicken.
- Öffne als normaler Nutzer Admin-Adressen. Sie sollten abgelehnt werden.
Geheimnisse (5 Minuten)
- Frag die KI mit dem Prompt von oben, wo jeder Schlüssel liegt.
- Öffne die App, zeige den Seitenquelltext an und suche nach „key“, „secret“ und „token“.
Formulare und Missbrauch (5 Minuten)
- Sende jedes Formular leer ab, mit sehr langen Texten und zweimal kurz hintereinander.
- Prüfe, ob Rate-Limits für Anmeldung, Login und jede KI-Funktion existieren.
Daten und Wiederherstellung (5 Minuten)
- Wisse, wo die Daten liegen und wie du sie wiederherstellst.
- Prüfe, ob du den Code auf eine frühere funktionierende Version zurücksetzen kannst.
Recht und Grundlagen (5 Minuten)
- Wenn du persönliche Daten erhebst, ergänze eine Datenschutzerklärung und sag, was du erhebst. Siehe So schreibst du Nutzungsbedingungen und eine Datenschutzerklärung.
- Stelle sicher, dass die veröffentlichte App HTTPS verwendet. Die meisten Builder, Mythex eingeschlossen, kümmern sich darum für dich.
Wenn alles besteht, bist du für einen frühen Launch gut aufgestellt. Wiederhole die Schritte 1–5 nach jeder größeren Änderung an Login, Rollen oder Daten.
Was Vibe-Coding-Plattformen schützen und was nicht
Eine gute Plattform übernimmt einen Großteil der Infrastruktur: HTTPS, isolierte Arbeitsbereiche, eine Datenbank pro Projekt, Speicherung von Geheimnissen, Backups und Zurücksetzen. Mythex gibt jedem Projekt einen eigenen privaten Arbeitsbereich und eine eigene Datenbank, hält Geheimnisse aus dem Code heraus und speichert nach jeder erfolgreichen Änderung einen Checkpoint, damit du sie rückgängig machen kannst.
Was keine Plattform kann: die Regeln deiner App kennen. Nur du weißt, dass Kunden die Rechnungen anderer nicht sehen dürfen oder dass ein Gutscheincode nur einmal funktionieren soll. Diese Regeln müssen in deinen Prompts stehen und durch deine Tests bestätigt werden.
Die kurze Antwort
Vibe Coding ist so sicher wie die Prüfungen, die du ergänzt. Für ein persönliches Tool: Schlüssel aus dem Code heraushalten und Spaß haben. Bei allem, was fremde Daten enthält, führe vor jedem Launch den 30-Minuten-Check oben durch und lass eine Entwicklerin oder einen Entwickler bei Zahlungen und sensiblen Daten draufschauen. Um diese Risiken in echten Projekten zu sehen, lies unsere Beispiele für Vibe Coding; um von Anfang an mit diesen Prüfungen zu bauen, folge So baust du eine App mit Vibe Coding.
Fragen
Ist Vibe Coding sicher?
Für persönliche Tools und Prototypen ohne sensible Daten ja. Bei Apps, in denen sich andere anmelden, Daten speichern oder bezahlen, ist es nur sicher, wenn du die Prüfungen ergänzt, die Vibe Coding überspringt: serverseitige Zugriffsregeln, Geheimnisse außerhalb des Codes, Limits für öffentliche Formulare und eine Prüfung aller Teile, die mit Geld oder persönlichen Daten arbeiten.
Was ist das größte Sicherheitsrisiko bei Vibe-Coding-Apps?
Fehlende Zugriffskontrolle: Ein angemeldeter Nutzer kann die Daten eines anderen Nutzers lesen oder ändern, meist indem er eine ID in einer Anfrage austauscht. Beim Testen mit dem eigenen Konto fällt das nie auf, deshalb ist es so verbreitet. Prüfe es gezielt mit zwei Konten.
Kann KI-generierter Code meine API-Schlüssel preisgeben?
Ja, wenn der Schlüssel in Code landet, der im Browser des Besuchers läuft, oder in einem öffentlichen Repository committet wird. Bewahre Schlüssel in den Geheimnissen oder Umgebungsvariablen deines Tools auf, rufe externe Dienste vom Server aus auf und lass dir von der KI auflisten, wo jeder Schlüssel verwendet wird.
Brauche ich einen Entwickler, der eine Vibe-Coding-App prüft?
Nicht für ein persönliches Tool oder einen frühen Prototyp. Lass eine Entwicklerin oder einen Entwickler draufschauen, bevor du direkt Zahlungen annimmst, Gesundheits-, Finanz- oder Kinderdaten speicherst oder die App für viele Nutzer öffnest. Ein Export oder der GitHub-Zugriff macht diese Prüfung einfach zu organisieren.
Sind mein Code und meine Daten auf einer Vibe-Coding-Plattform sicher?
Das hängt von der Plattform ab, lies also ihre Seiten zu Sicherheit und Datenschutz. Bei Mythex läuft jedes Projekt in seinem eigenen privaten Arbeitsbereich mit eigener Datenbank, Geheimnisse werden außerhalb des Codes gespeichert, und Checkpoints erlauben dir, eine fehlerhafte Änderung rückgängig zu machen. Die eigene Logik deiner App braucht trotzdem die Prüfungen aus diesem Leitfaden.