Vibe Coding Sicherheit: Probleme, die wir in KI-generierten Apps prüfen

Vibe Coding Sicherheit dreht sich hauptsächlich darum, was KI-generierte Apps weglassen: serverseitige Autorisierung für jeden Datensatz, Geheimnisse, die nicht auf dem Client gespeichert werden, gesperrte Datenbankregeln, validierte Eingaben, sichere Zahlungs-Webhooks und Ratenbegrenzungen. Überprüfen Sie diese Vertrauensgrenzen vor dem Start, denn die App kann fertig aussehen, während jeder angemeldete Benutzer die Daten aller anderen lesen kann.

Dies ist die Checklisten-Ebene unserer Prototyp-zu-Produktion-Arbeit. Für die allgemeine Härtungsreihenfolge siehe wie man einen Lovable- oder v0-Prototyp in eine Produktionsanwendung umwandelt. Speziell für Agenten siehe die Grenzen des Aufbaus von Agenten nur mit Vibe-Code-Tools. Hier listen wir die konkreten Probleme auf, nach denen wir in KI-erstellten Web- und Mobil-Apps suchen, basierend auf gängigen Vertrauensgrenzen-Mustern und der ImadDhin-Portalimplementierung. Nichts davon ist eine Behauptung über Statistik von Sicherheitsverletzungen.

Warum KI-generierte Apps vorhersehbare Lücken haben

KI-Codierungstools sind darauf optimiert, etwas zu produzieren, das funktioniert, wenn man es ausprobiert. Sicherheitseigenschaften sind meist unsichtbar, wenn man etwas ausprobiert. Eine Seite, die Ihre eigenen Bestellungen anzeigt, sieht identisch aus, egal ob der Server die Eigentümerschaft überprüft oder einfach die vom Browser angeforderte Bestell-ID zurückgibt.

Der Ersteller testet auch als einzelner Benutzer, normalerweise der Eigentümer, mit vollem Zugriff. Jeder Ablauf funktioniert, weil nichts jemals verweigert wird. Wenn ein Berechtigungsfehler auftritt, ist die schnellste Aufforderung, ihn zu beseitigen, oft, eine Regel zu lockern, und das Tool kommt dem nach.

Generierter Code erbt auch Muster aus Tutorials und Starter-Vorlagen, wo Schlüssel in der Client-Konfiguration liegen und Datenbankregeln der Einfachheit halber offen gelassen werden. Diese Muster sind für eine Demo in Ordnung und für Kunden falsch.

Was machen Teams bei der Sicherheit von KI-generiertem Code falsch?

Die meisten Fehler behandeln die Plattform, die Schnittstelle oder das KI-Tool selbst als Sicherheitsüberprüfung. Die häufigsten sind:

– Annahme, dass eine gehostete Plattform oder ein Backend-as-a-Service die App standardmäßig sicher macht

– Schaltflächen in der Benutzeroberfläche verstecken und dies als Autorisierung behandeln

– Dasselbe KI-Tool fragen, ob sein Code sicher ist, und die Antwort als Überprüfung akzeptieren

– Datenbankregeln lockern, um einen Berechtigungsfehler zu beheben, anstatt die Abfrage zu korrigieren

– Die Sicherheitsüberprüfung für nach dem Start planen

Die Plattformen bieten gute Bausteine, aber die Konfiguration und die Autorisierungslogik liegen bei Ihnen. Die Überprüfung muss von jemandem durchgeführt werden, der nach Fehlern sucht, nicht von dem Tool, das den Code geschrieben hat.

Was steht auf einer Vibe Coding Sicherheit-Checkliste?

Die Checkliste deckt acht Vertrauensgrenzen ab, von der Authentifizierung bis zum Betrieb, und jeder Punkt benennt eine Grenze, die bewusst überprüft werden sollte. Autorisierung steht aus gutem Grund an erster Stelle: Broken Access Control steht an der Spitze der OWASP Top 10.

Authentifizierung und Konten

– Passwort-Reset- und E-Mail-Verifizierungsabläufe können nicht wiederholt oder übersprungen werden

– OAuth-Weiterleitungs-URLs sind auf bekannte Domains beschränkt

– Rollen wie Admin stammen aus einer servergesteuerten Quelle, niemals aus einem Profilfeld, das der Benutzer bearbeiten kann

– Sitzungen laufen ab und die Abmeldung invalidiert, was sie sollte

Autorisierung für jeden Datensatz

– Jedes Lesen und Schreiben überprüft die Eigentümerschaft oder Mandantenfähigkeit auf dem Server oder in Datenbankregeln

– Das Ändern einer ID in einer Anfrage kann den Datensatz eines anderen Benutzers nicht zurückgeben oder ändern

– Admin-Routen und API-Endpunkte sind serverseitig geschützt, nicht nur in der Navigation versteckt

– Listen-Endpunkte filtern nach dem aktuellen Benutzer oder Mandanten, nicht nur nach dem, was die Seite anzeigt

Datenbank- und Speicherregeln

– Row-Level Security oder gleichwertige Regeln sind für jede exponierte Tabelle oder Sammlung aktiviert

– Keine Regel erlaubt uneingeschränkte Lese- oder Schreibzugriffe aus Bequemlichkeit

– Erstellungsregeln validieren die Form und Eigentümerschaft neuer Datensätze

– Dateispeicher-Buckets haben eigene Regeln und erlauben keine öffentliche Auflistung

Für Supabase-Projekte ist dies ein eigenes Thema, das in Supabase Row-Level Security Fehler in KI-erstellten Apps behandelt wird.

Geheimnisse und Konfiguration

– Keine Service-Rollen-, Admin- oder Zahlungsgeheimschlüssel in Client-Code oder öffentlichen Umgebungsvariablen

– Keine Geheimnisse in committeten Dateien, einschließlich des Verlaufs

– Produktions-Source-Maps legen keine Serverlogik oder Schlüssel offen

– CORS ist eingeschränkt und Sicherheits-Header sind gesetzt

Eingabe, Ausgabe und KI-Funktionen

– Serverseitige Validierung jeder Eingabe, nicht nur im Formular

– Benutzerinhalte, die als Markdown oder HTML gerendert werden, sind bereinigt

– Datei-Uploads prüfen Typ und Größe und werden außerhalb des Web-Roots gespeichert

– Funktionen, die URLs abrufen, können keine internen Netzwerkadressen erreichen, das klassische Risiko der Server-Side Request Forgery

– Modellausgabe wird als nicht vertrauenswürdig behandelt und kann ohne Überprüfung keine Aktionen auslösen

– Modell-Anbieter-Schlüssel werden nur auf dem Server verwendet

Zahlungen und Berechtigungen

– Preise und Plan-IDs werden auf dem Server festgelegt, niemals vom Client übernommen

– Webhook-Signaturen werden verifiziert, bevor sie verarbeitet werden

– Webhook-Handler sind idempotent, sodass ein wiederholtes Ereignis den Zugriff nicht zweimal gewährt

– Der Zugriff wird vom verifizierten Zahlungsereignis gewährt, nicht vom Erreichen einer Erfolgsseite

Missbrauch und Kosten

– Ratenbegrenzungen für Anmeldung, Registrierung, Passwort-Reset und KI-Endpunkte

– Quoten- und Guthabenzähler werden atomar aktualisiert

– Öffentliche Formulare verfügen über Bot-Schutz proportional zu ihrem Risiko

Abhängigkeiten und Operationen

– Jedes hinzugefügte Paket existiert, ist das beabsichtigte und wird gewartet

– Debug-Routen, Seed-Endpunkte und Testkonten werden entfernt

– Fehler, die Benutzern angezeigt werden, enthalten keine Stack-Traces oder Abfragen

– Sicherheitsrelevante Ereignisse wie Anmeldungen, Rollenänderungen und Admin-Aktionen werden ohne Geheimnisse oder unnötige persönliche Daten protokolliert

Wie führt man eine Sicherheitsüberprüfung einer KI-erstellten App durch?

Führen Sie sie in vier Schritten durch: ein kurzes Bedrohungsmodell, externe Tests, Fehlerbehebungen nach Explosionsradius geordnet und automatisierte Prüfungen, die die Korrekturen beibehalten. Beginnen Sie mit dem Bedrohungsmodell: welche Daten die App enthält, wer sie sehen sollte, was ein Angreifer wollen würde und welche Aktionen Geld kosten. Eine Stunde davon konzentriert den Rest der Überprüfung.

Testen Sie dann wie ein Außenstehender. Erstellen Sie zwei gewöhnliche Konten und versuchen Sie, die Daten des jeweils anderen über die Benutzeroberfläche und direkt über die API zu lesen, zu ändern und zu löschen. Fragen Sie die Datenbank mit dem öffentlichen Clientschlüssel ab, während Sie abgemeldet sind. Durchsuchen Sie das erstellte Client-Bundle nach allem, was wie ein Schlüssel aussieht. Wiederholen Sie einen Zahlungs-Webhook. Senden Sie dieselbe Anfrage viele Male schnell. Diese Tests finden mehr reale Probleme als das alleinige Lesen von Code.

Beheben Sie in der Reihenfolge des Explosionsradius: zuerst exponierte Geheimnisse und offene Datenbankregeln, da sie jeden Benutzer gleichzeitig betreffen; dann Autorisierungslücken; dann Zahlungen; dann Missbrauchsgrenzen und Härtung. Rotieren Sie jedes Geheimnis, das jemals, auch nur kurz, exponiert war, anstatt es nur aus dem Code zu entfernen.

Sorgen Sie schließlich dafür, dass die Korrekturen dauerhaft sind. Fügen Sie die kontoübergreifenden Tests zu Ihrer automatisierten Suite hinzu, stellen Sie Regeldateien zur Überprüfung bereit und fügen Sie dem Repository eine Geheimnisprüfung hinzu, damit die nächste KI-generierte Änderung nicht stillschweigend dieselben Lücken wieder öffnen kann.

Was eine Sicherheitsüberprüfung kostet und wann man leichter vorgehen sollte

Eine Überprüfung kostet ein paar Tage vor dem Start und einige Funktionen, die auf offenem Zugriff beruhten, und ihre Tiefe sollte den beteiligten Daten und Geldern entsprechen. Strenge Datenbankregeln brechen manchmal Funktionen, die auf offenem Zugriff beruhten. Dieser Bruch ist nützlich: er zeigt, welche Abfragen sich auf die Lücke verlassen haben. Die Behebung der Abfrage ist mehr Arbeit als die Wiederherstellung der offenen Regel, und es ist die einzige Korrektur, die hält.

Eine gründliche Überprüfung verlangsamt den Start für die meisten Prototypen um Tage, nicht um Monate. Die Alternative ist, dieselben Probleme zu entdecken, nachdem Kunden der App ihre Daten anvertraut haben, wenn Korrekturen auch Benachrichtigung, Rotation und Bereinigung erfordern.

Nicht jedes Ergebnis rechtfertigt den gleichen Aufwand. Ein intern mit Testdaten verwendeter Prototyp benötigt weniger als eine öffentliche App, die Zahlungen entgegennimmt. Passen Sie die Tiefe der Überprüfung an die beteiligten Daten und Gelder an.

Muster, die wir in unseren eigenen Regeln und in Code-Reviews sehen

Dies sind Beobachtungen auf Code-Ebene aus der Konfiguration des ImadDhin-Portals und vorgeschlagenen Überprüfungsprüfungen, keine Behauptungen über Client-Vorfälle.

Die Datenbankregeln des Portals verweigern den Zugriff standardmäßig, ohne eine Catch-All-Regel. Chat-Sitzungen, Nachrichten, gespeicherter Speicher und Nutzungsaufzeichnungen werden Clients vollständig verweigert und nur von Server-Routen verarbeitet. Mehrere öffentliche Erfassungssammlungen erlauben das Erstellen, aber nicht das Lesen, Aktualisieren oder Löschen, wobei Validierungsfunktionen die Form jedes neuen Datensatzes überprüfen.

Ein lehrreiches Fehlermuster ist eine Erfassungsregel, die jede Erstellung akzeptiert, weil ein Server über das Client-SDK in diese Sammlung schreibt. Datenbankregeln können einen Server, der das Client-SDK verwendet, nicht von einem Browser unterscheiden, sodass eine Regel, die geschrieben wurde, um den Server hereinzulassen, jeden hereinlässt. Behandeln Sie dieses Muster als Befund: Schreiben Sie vom Server mit administrativen Anmeldeinformationen und verweigern Sie Client-Schreibvorgänge, oder fügen Sie dieselbe Formvalidierung hinzu, die die anderen Sammlungen verwenden.

Nutzungszähler sind das zweite Muster. Ein Zähler, der den aktuellen Zählerstand liest und dann den inkrementierten Wert in einem separaten Schritt außerhalb einer Transaktion schreibt, lässt zwei gleichzeitige Anfragen die Grenzwertprüfung passieren. Bei einer kleinen Freimenge ist das Risiko gering, aber dasselbe Muster, das ein bezahltes Guthaben schützt, ist eine echte Schwachstelle, und es ist genau die Art von Code, die eine schnelle Überprüfung besteht.

Server-Geheimnisse werden zur Laufzeit auf dem Server aufgelöst, zuerst aus der Umgebungskonfiguration und dann aus einem Geheimnis-Manager, und keines verwendet ein öffentliches Präfix. Deploy-Ignore-Regeln sind ein nützlicher Rückhalt, aber die stärkere Gewohnheit ist, Anmeldeinformationsdateien vollständig außerhalb des Repositorys zu halten, sodass eine einzelne falsch konfigurierte Regel sie nicht offenlegen kann.

Welche Tests finden Sicherheitslücken in einer KI-erstellten App?

– Melden Sie sich als Benutzer B an und fordern Sie die Datensätze von Benutzer A per ID über die API an

– Fragen Sie jede Tabelle oder Sammlung mit dem öffentlichen Clientschlüssel ab, während Sie abgemeldet sind

– Durchsuchen Sie das Produktions-Bundle und die Source Maps nach geheim aussehenden Zeichenfolgen

– Wiederholen Sie einen Zahlungs-Webhook und bestätigen Sie, dass der Zugriff nur einmal gewährt wird

– Bearbeiten Sie Ihr eigenes Profil, um eine Administratorrolle hinzuzufügen, und prüfen Sie, ob dies keine Auswirkungen hat

– Senden Sie parallele Anfragen an eine Quotenbegrenzung und bestätigen Sie, dass diese eingehalten wird

– Fügen Sie ein Skript-Tag in ein Textfeld ein, das an anderer Stelle gerendert wird

Wann ist eine leichtere Sicherheitskonfiguration ausreichend?

Wenn die App ein interner Prototyp mit gefälschten Daten ist, besteht die einfachste Sicherheitsmaßnahme darin, sie nicht öffentlich zugänglich zu machen: Halten Sie sie hinter einer Authentifizierung oder einem privaten Netzwerk, bis sie für echte Daten bereit ist.

Wenn die App nur eine Anmeldung und ein paar Seiten benötigt, verwenden Sie die verwaltete Authentifizierung Ihrer Plattform und die restriktivsten Standardregeln und vermeiden Sie benutzerdefinierte Rollen, bis Sie sie benötigen. Weniger Funktionen bedeuten weniger Vertrauensgrenzen, die überprüft werden müssen. Manchmal ist die beste Sicherheitskorrektur das Entfernen einer Funktion, die niemand verwendet.

Führen Sie die Überprüfung durch, bevor Kunden die Lücken finden

Führen Sie die Checkliste aus, testen Sie mit zwei Konten und einem abgemeldeten Client und beheben Sie Fehler nach Explosionsradius. Wenn Sie die Überprüfung und Fehlerbehebung lieber für sich erledigen lassen möchten, sehen Sie sich die Vibe-Code-Rettung von ImadDhin an, senden Sie Ihre Repository-Details über das Projektbriefing oder buchen Sie einen 30-minütigen Anruf.

Wie können Sie Cybersicherheitsrisiken vor einer Bewertung erkunden?

Das interaktive Cybersicherheitslabor verwendet synthetische Anfragen, um Kassenmanipulation, gefälschte Zahlungsereignisse, Mandantenisolation, exponierte Geheimnisse und KI-Tool-Genehmigungen zu veranschaulichen. Lösen Sie einen Fehler aus, aktivieren Sie eine Schutzmaßnahme und wiederholen Sie dasselbe Ereignis, bevor Sie den Rest aktivieren. Der Schutz eines Preises begründet nicht die Eigentümerschaft der Bestellung, und das Verschieben eines Schlüssels auf den Server widerruft keine exponierte Kopie.

Xion im Cybersicherheits-Showcase ist eine Konzeptdemonstration von Zulassungs-, Blockierungs- und Genehmigungsentscheidungen. Es überwacht oder schützt Ihre Anwendung nicht. Für Ihre Plattform müssen Beweise aus gezielten Tests der tatsächlichen Autorisierungs-, Zahlungs- und Datengrenzen stammen. Verwenden Sie das Labor, um Überprüfungsfragen zu identifizieren, und überprüfen Sie dann die Implementierung in der relevanten Umgebung.