Sicherheitsrisiken beim Vibe Coding: 8 Dinge, die Sie vor dem Launch prüfen sollten

„Vibe Coding“ bedeutet, Software zu entwickeln, indem man einer KI beschreibt, was man möchte, und akzeptiert, was sie liefert. Dadurch ist das Bauen von Apps für Gründer, Designer und Fachanwender in Reichweite gerückt, die vor ein oder zwei Jahren noch nicht programmieren konnten. Es hat aber auch eine neue Art von Sicherheitslücke geschaffen: Software, die funktioniert, fertig aussieht und nie von jemandem geprüft wurde, der wie ein Angreifer denkt.

Dieser Leitfaden listet die acht Sicherheitsrisiken auf, die wir in einer per Vibe Coding erstellten App zuerst prüfen würden, warum sie entstehen und was Sie dagegen tun können. Für keines davon müssen Sie Code lesen. Sie müssen die richtigen Fragen stellen, bevor echte Nutzer kommen.

Warum KI-generierte Apps ein eigenes Risikoprofil haben

KI-Tools optimieren auf „es funktioniert“. Scheitert eine Anfrage an einer Berechtigung, ist der schnellste Weg zur Lösung oft, die Berechtigung zu entfernen. Wird ein API-Schlüssel benötigt, legt man ihn am schnellsten dort ab, wo der Code ihn erreicht – das kann der Browser sein. Die App besteht jeden Test des Entwicklers, weil diese Tests als Eigentümer ausgeführt werden.

Deshalb sind die folgenden Schwächen selten dramatische Code-Fehler. Es sind fehlende Entscheidungen: Wer darf das tun, wo soll dieses Secret liegen, was passiert, wenn jemand diese Funktion missbraucht.

Risiko 1: fehlerhafte Zugriffskontrolle

Das häufigste und schwerwiegendste Problem. Ein Kunde kann die Datensätze eines anderen lesen, ändern oder löschen, oder ein normaler Nutzer erreicht Admin-Funktionen, weil Prüfungen nur in der Oberfläche existieren und nicht auf dem Server oder in der Datenbank. In Supabase-Projekten bedeutet das meist fehlende oder schwache Row Level Security, die wir in sieben RLS-Fehlern von KI-gebauten Apps behandeln.

Test: Verwenden Sie zwei Konten und versuchen Sie, auf die Daten des jeweils anderen zuzugreifen, indem Sie IDs in URLs und Anfragen ändern.

Risiko 2: offengelegte Secrets

API-Schlüssel, Datenbankpasswörter und Service-Tokens landen im Frontend-Code, in öffentlichen Repositories oder in Chatverläufen. Alles, was an den Browser ausgeliefert wird, ist öffentlich, und in Git committete Schlüssel bleiben auch nach dem Löschen der Datei in der Historie erhalten.

Lösung: Halten Sie Secrets in serverseitigen Umgebungsvariablen, durchsuchen Sie Bundle und Repository nach Schlüsseln und rotieren Sie alles, was jemals offengelegt wurde.

Risiko 3: nicht validierte Eingaben

Formulare, URLs und API-Parameter werden vom Angreifer kontrolliert. Baut die App Datenbankabfragen durch das Verketten von Strings auf oder gibt sie Nutzereingaben ohne Kodierung auf Seiten aus, kann sie für SQL-Injection oder Cross-Site-Scripting anfällig sein. Moderne Frameworks und Query Builder verhindern das meiste davon standardmäßig, doch generierter Code umgeht sie mitunter.

Lösung: Verwenden Sie parametrisierte Abfragen, validieren Sie Eingaben auf dem Server und prüfen Sie jede Stelle, an der Raw-Queries oder rohes HTML erzeugt werden.

Risiko 4: halluzinierte und veraltete Abhängigkeiten

KI-Tools schlagen manchmal Softwarepakete vor, die gar nicht existieren. Angreifer haben begonnen, solche Namen mit schädlichem Code zu registrieren, in der Hoffnung, dass ein Entwickler oder ein automatisiertes Tool sie installiert. Das wird manchmal Slopsquatting genannt. Unabhängig davon fixieren generierte Projekte oft alte Versionen mit bekannten Schwachstellen.

Lösung: Prüfen Sie, ob jede Abhängigkeit existiert, weit verbreitet ist und die gewünschte ist, committen Sie Ihre Lockfile und führen Sie bei jedem Build einen Schwachstellenscan der Abhängigkeiten durch.

Risiko 5: unsichere Standardeinstellungen

Beispiele sind eine zu großzügige Cross-Origin-Einstellung, die jeder Website erlaubt, Ihre API aufzurufen, im Produktivbetrieb aktiv gebliebener Debug-Modus, detaillierte Fehlermeldungen, die Interna preisgeben, öffentliche Storage-Buckets und Standard-Adminkonten. Jedes davon ist eine Änderung in einer Zeile, und jedes ist leicht zu übersehen.

Lösung: Prüfen Sie die Produktionskonfiguration getrennt von der Entwicklung und schalten Sie alles ab, was nur der Bequemlichkeit dient.

Risiko 6: keine Grenzen für Nutzung oder Kosten

Apps mit KI-Funktionen rufen häufig im Namen jedes Besuchers ein kostenpflichtiges Modell auf. Ohne Rate Limits, Kontingente pro Nutzer und Ausgabenobergrenzen kann ein Skript eine hohe Rechnung verursachen oder den Dienst lahmlegen. Login- und Registrierungsformulare ohne Limits laden zum Erraten von Passwörtern und zu Bot-Registrierungen ein.

Lösung: Führen Sie Rate Limiting ein, setzen Sie Nutzungsobergrenzen für jeden Drittanbieter-Schlüssel und lassen Sie sich warnen, wenn die Ausgaben sprunghaft steigen.

Risiko 7: Prompt Injection in Ihren eigenen KI-Funktionen

Wenn Ihre App ein Modell Nutzerinhalte lesen, Seiten durchsuchen oder Tools aufrufen lässt, können Angreifer in diesen Inhalten Anweisungen verstecken, um das Modell zu steuern. Die Gefahr steigt mit dem, was das Modell tun kann: private Daten lesen, Nachrichten senden oder Datensätze ändern. Die Angriffsarten und das Testen erklären wir in unserem Leitfaden zu LLM-Red-Teaming im Vergleich zu einem Penetrationstest für Web-Apps.

Lösung: Geben Sie den Tools des Modells möglichst wenige Rechte, verlangen Sie bei riskanten Aktionen eine menschliche Freigabe und behandeln Sie alles, was das Modell ausgibt, als nicht vertrauenswürdig.

Risiko 8: kein Logging, also keine Möglichkeit, es zu erfahren

Viele per Vibe Coding erstellte Apps können grundlegende Fragen nicht beantworten, nachdem etwas schiefgegangen ist: wer auf was zugegriffen hat, wann der Fehler begann, welche Anfrage fehlschlug. Ohne Logs und Monitoring kann ein Vorfall wochenlang laufen, bevor es jemand bemerkt, und Sie können nicht nachvollziehen, was offengelegt wurde.

Lösung: Zentralisieren Sie Fehlerprotokolle, führen Sie Audit-Logs für sensible Aktionen und richten Sie Alarme ein, die eine echte Person erreichen.

Ein 30-minütiger Sicherheitscheck, den Sie heute durchführen können

1. Legen Sie zwei Testkonten an und versuchen Sie, die Daten des jeweils anderen zu sehen, zu ändern und zu löschen.
2. Durchsuchen Sie Ihr Repository und den Code Ihrer gebauten Website nach API-Schlüsseln und Service-Tokens.
3. Prüfen Sie, welche Storage-Buckets und Datenbanktabellen öffentlich lesbar sind.
4. Öffnen Sie die Netzwerkanfragen Ihrer App und suchen Sie nach Secrets, internen URLs oder ausführlichen Fehlermeldungen.
5. Listen Sie jede Abhängigkeit auf und bestätigen Sie, dass sie echt, aktuell und beabsichtigt ist.
6. Bestätigen Sie, dass Rate Limits und Ausgabenobergrenzen für Login, Registrierung und jede KI-Funktion existieren.
7. Prüfen Sie, dass Fehler und sensible Aktionen an einem Ort protokolliert werden, den Sie lesen können.

Was KI-Tools hier leisten können und was nicht

Sie können die KI bitten, ihren eigenen Code auf diese Probleme zu prüfen, und sie wird einige finden. Sie arbeitet jedoch mit denselben Annahmen, die das Problem verursacht haben, und kann Ihr bereitgestelltes System nicht mit zwei echten Konten testen. Betrachten Sie eine KI-Sicherheitsprüfung als erste Durchsicht, nicht als Freigabe.

Wenn es um echte Nutzer, personenbezogene Daten oder Zahlungen geht, ziehen Sie eine unabhängige Person hinzu. Ein technisches Audit für KI-Apps deckt Zugriffskontrolle, Secrets, Datenberechtigungen, Zahlungen und Deployment ab und endet mit einer priorisierten Korrekturliste. Wenn Sie bereits wissen, was defekt ist, behebt die Reparatur und der Produktions-Launch von KI-Apps es und veröffentlicht die App kontrolliert. Unsere Produktions-Checkliste mit 20 Punkten fasst diese Prüfungen zusammen.