Im März 2026 stellten Forscher der Georgia Tech 35 neue CVEs direkt auf KI-generierten Code zurück. Allein dieser Monat produzierte mehr Schwachstellen als das gesamte Jahr 2025, und dasselbe Team schätzt, dass die tatsächliche Zahl über Open Source fünf- bis zehnmal höher liegt.
Wenn Ihr Produkt mit Lovable, Bolt, Cursor oder Replit erstellt wurde, sollte diese Information neu definieren, was für Sie “bereit zum Start” bedeutet. Der Code läuft. Benutzer registrieren sich. Die Demo sieht großartig aus. Nichts davon sagt Ihnen, ob ein Fremder mit zwanzig Minuten Ihre gesamte Benutzertabelle einsehen kann. Die Sicherheitsrisiken des Vibe-Codings in diesen Codebasen konzentrieren sich auf dieselben vorhersagbaren Stellen, unabhängig davon, welches Tool den Code generiert hat.
Ein Vibe-Code-Audit ist eine strukturierte Überprüfung von KI-generiertem Code, die die Probleme aufzeigt, die der Produktionsverkehr zuerst findet. Audit-Arbeiten wie die Vibe-Code-Bereinigung verbessern die Wartbarkeit durchweg um 80–90 %, und dieselben zehn Befunde sind normalerweise das, was sie zurückhält.
Warum KI-generierter Code in der Produktion fehlschlägt
Geschwindigkeit ist das gesamte Verkaufsargument des Vibe-Codings. Tools wie Cursor und Lovable optimieren für funktionierende Ergebnisse, nicht für sichere Ergebnisse. Das sind nicht dasselbe, und die Lücke ist genau das, was eine ordnungsgemäße Vibe-Code-Code-Überprüfung schließen soll.
Die Cloud Security Alliance überprüfte die Veracode-Forschung über mehr als 100 große Sprachmodelle und stellte fest, dass 45 % der KI-generierten Codebeispiele OWASP Top 10-Schwachstellen einführen. Die Erfolgsquote hat sich von 2025 bis 2026 trotz gegenteiliger Behauptungen der Anbieter nicht wesentlich verbessert.
Eine funktionierende Demo besteht den Augentest. Sie prüft nicht, ob Ihr Authentifizierungsablauf leckt, ob Ihre Datenbank die Zeilen anderer Benutzer zurückgibt oder ob eine halluzinierte Abhängigkeit gerade in die Produktion gelangt ist. Wenn Sie Softwareentwicklung für Startups schnell betreiben, müssen Sie KI-generierten Code mit der gleichen Sorgfalt prüfen, die Sie auch auf einen Pull-Request eines Junior-Entwicklers anwenden würden. Das gleiche Risiko erstreckt sich auf den Bereich der Erkennung von Shadow-KI: Code, der über Ingenieurteams ausgeliefert wird, bei denen niemand verfolgt, wie viel davon die KI geschrieben hat.
Die 10 kritischen Prüfungen vor dem Start
Diese zehn Prüfungen stammen aus realer Audit-Arbeit und sind nach Häufigkeit ihres Auftretens und dem verursachten Schaden geordnet. Jede davon gehört in jede gründliche Überprüfung von Vibe-Code-Anwendungen vor dem Start. Einige können Sie in fünf Minuten mit einem schnellen Scan überprüfen. Andere erfordern, dass ein leitender Ingenieur Ihren Code von Hand liest. Führen Sie sie in dieser Reihenfolge aus, um zu erkennen, was die meisten Vibe-Code-Anwendungen zum Absturz bringt, bevor zahlende Benutzer es für Sie finden.
1. Offengelegte Geheimnisse und API-Schlüssel
Der mit Abstand häufigste Fehler in KI-generiertem Code. KI-Tools betten regelmäßig Anmeldeinformationen in clientseitige Bundles ein oder committen sie in öffentliche Repositories. Sobald ein Schlüssel heraus ist, ist er heraus. Die Rotation kostet Geld, Zeit und Kundenvertrauen.
Eine Vibe-Code-Social-Plattform namens Moltbook leckte laut Infosecurity Magazine 1,5 Millionen Authentifizierungstoken innerhalb von drei Tagen nach dem Start. Der Gründer sagte später öffentlich, dass er keine einzige Zeile Code geschrieben habe. Er hatte auch keine überprüft.
Überprüfen Sie drei Orte: clientseitige JavaScript-Bundles, in Git committete Umgebungsvariablen und CI/CD-Konfigurationen. Führen Sie einen Secret-Scanner wie TruffleHog oder GitGuardian für Ihren gesamten Commit-Verlauf aus, nicht nur für den aktuellen Branch. Wenn Sie etwas finden, rotieren Sie zuerst die Schlüssel und bereinigen Sie dann den Git-Verlauf.
2. Serverseitige Authentifizierung
KI-Tools lieben ein sauberes Komponentenmuster. Sie fügen eine isAdmin-Prüfung im Frontend hinzu und sind damit fertig. Aus Sicht der Benutzererfahrung ist das Dashboard korrekt ausgeblendet. Aus Sicherheitssicht kann jeder mit den Browser-Entwicklertools den Schalter umlegen und hineinspazieren.
Jeder geschützte Endpunkt muss die Identität auf dem Server überprüfen, wobei ein Token bei jeder Anfrage gegen Ihren Authentifizierungsanbieter validiert wird. Nicht der Cookie. Nicht der Wert im lokalen Speicher. Das signierte Token, serverseitig geprüft.
Führen Sie einen schnellen Test durch: Melden Sie sich ab, kopieren Sie eine Anfrage an einen geschützten Endpunkt, spielen Sie sie erneut ab, nachdem der Authentifizierungsheader entfernt wurde. Wenn die Daten zurückkommen, ist dieser Endpunkt offen. Wiederholen Sie dies für jede privilegierte Route.
3. Zeilenbasierte Sicherheit und Autorisierung (IDOR)
Authentifizierung teilt dem Server mit, wer Sie sind. Autorisierung teilt dem Server mit, was Sie sehen dürfen. KI-Tools erledigen den ersten Teil einigermaßen gut. Den zweiten Teil fast nie.
Der klassische Bruch ist eine unsichere direkte Objektverweigerung (Insecure Direct Object Reference). Benutzer A meldet sich normal an, ändert eine numerische ID in der URL und liest die Daten von Benutzer B. Bei Supabase bedeutet dies normalerweise, dass die zeilenbasierte Sicherheit auf Datenbankebene deaktiviert oder nur teilweise konfiguriert ist.
Testen Sie, wie ein Angreifer es tun würde. Melden Sie sich als Testbenutzer an und versuchen Sie dann, eine Ressource zu lesen, zu aktualisieren oder zu löschen, die einem anderen Benutzer gehört. Wenn einer dieser Aufrufe erfolgreich ist, haben Sie einen Autorisierungsfehler. Beheben Sie ihn auf Datenbankebene, nicht nur auf API-Ebene.
4. Eingabevalidierung und -bereinigung
Jedes Formularfeld, jeder Abfrageparameter und jeder JSON-Body, der in Ihre API gelangt, ist feindlich, bis das Gegenteil bewiesen ist. KI-Tools vertrauen der Eingabe standardmäßig, was die Tür für SQL-Injection, Cross-Site-Scripting und Server-Side Request Forgery öffnet.
Forschungen der Cloud Security Alliance beziffern die Rate der OWASP Top 10-Schwachstellen in KI-generiertem Code auf 45 %, wobei Cross-Site Scripting und SQL Injection als die häufigsten Muster genannt werden.
Validieren Sie die Eingabe an der Grenze, bevor sie Ihre Geschäftslogik berührt. Verwenden Sie für jeden Datenbankaufruf mit parametrisierten Abfragen und ohne Ausnahmen. Bereinigen Sie alles, was als HTML gerendert wird. Überprüfen Sie für Datei-Uploads Typ, Größe und Inhalt. Die Funktionen sind kurz und in jedem modernen Framework gut dokumentiert.
5. Ratenbegrenzung für kritische Endpunkte
Zwei Arten von Endpunkten versagen in entgegengesetzter Richtung, wenn sie nicht ratenbegrenzt sind. Authentifizierungs-Endpunkte werden Brute-Force-Angriffen ausgesetzt. Externe API-Endpunkte werden zu einer Rechnung, die Sie am Montag nicht sehen möchten.
Die gleiche Logik gilt für alles, was einen ausgehenden Aufruf auslöst: SMS-Sendungen, E-Mail-Kampagnen, LLM-Anfragen, Zahlungsbestätigungen. Ein gelangweilter Angreifer mit einem Skript kann Ihr Monatsbudget in einer Stunde aufbrauchen.
Legen Sie vernünftige Standardwerte auf drei Ebenen fest: Anmeldeversuche pro IP pro Minute, API-Aufrufe pro authentifiziertem Benutzer pro Minute und teure ausgehende Operationen pro Benutzer pro Stunde. Die meisten Frameworks liefern standardmäßig Ratenbegrenzungs-Middleware. KI fügt sie selten unaufgefordert hinzu, also prüfen Sie explizit und prüfen Sie, bevor Zahlungen live gehen.
6. Sicherheits-Header und CORS
Browserbasierte Sicherheits-Header leisten stille, wichtige Arbeit. Sie sitzen zwischen Ihrem Server und dem Browser des Benutzers und verhindern ganze Angriffskategorien, gegen die Sie sonst in der Anwendungsebene kämpfen müssten.
Mindestens sollten Ihre Antworten Folgendes enthalten:
- Content-Security-Policy (blockiert eingeschleuste Skripte)
- Strict-Transport-Security (erzwingt HTTPS)
- X-Frame-Options (verhindert Clickjacking)
- X-Content-Type-Options (verhindert MIME-Sniffing)
- Referrer-Policy (steuert, welche URLs Sie preisgeben)
CORS verdient eine eigene Prüfung. KI-generierte Konfigurationen enthalten oft Access-Control-Allow-Origin: *, was bedeutet, dass jede Website im Internet authentifizierte Anfragen an Ihre API stellen kann. Schränken Sie CORS auf die genauen Domains ein, die Sie bedienen, und lehnen Sie alles andere ab.
7. Verifizierung von Webhook-Signaturen
Zahlungsanbieter, Kalenderdienste und die meisten modernen SaaS-Plattformen senden Updates an Ihre App über Webhooks. Jeder davon ist im Wesentlichen ein öffentlicher Endpunkt, den jeder im Internet aufrufen kann. Die Signatur ist das, was Ihnen sagt, dass der Aufruf tatsächlich von Stripe kam und nicht von einem zufälligen Skript, das Ihren Endpunkt gefunden hat.
KI-generierte Webhook-Handler überspringen häufig die Signaturprüfung vollständig. Die Integration funktioniert im Test, da niemand Aufrufe fälscht. Sie schlägt beim ersten Mal fehl, wenn eine Zahlung schiefgeht, oder schlimmer noch, ein Angreifer sendet ein gefälschtes “Abonnement bezahlt”-Ereignis und schaltet Premium-Funktionen kostenlos frei.
Verifizieren Sie für jeden Webhook-Empfänger die Signatur mit der Bibliothek des Anbieters, verwenden Sie Idempotenzschlüssel, um Wiederholungsversuche zu deduplizieren, und protokollieren Sie jede Nutzlast zur Fehlersuche.
8. Soft Deletes und GDPR-konforme Löschabläufe
Wenn ein Benutzer auf “Konto löschen” klickt, was passiert tatsächlich mit seinen Daten? In den meisten Vibe-Code-Apps wird die Zeile aus einer Tabelle entfernt, während der Rest des Systems weiterhin auf den fehlenden Datensatz verweist. Folge: mysteriöse Abstürze in der Produktion eine Woche später.
Zwei Probleme liegen dem zugrunde. Das erste ist die Technik: Sie benötigen Soft Deletes (eine deleted_at-Spalte anstelle einer DELETE-Anweisung), damit Ihre App konsistent bleibt. Das zweite ist rechtlich. Artikel 17 der DSGVO gibt EU-Bürgern ein Recht auf Löschung, und Sie müssen dieses in Protokollen, Sicherungen und Analysen einhalten, nicht nur in der primären Datenbank.
Ordnen Sie jeden Ort, an dem Benutzerdaten gespeichert sind, und erstellen Sie dann einen Löschvorgang, der alle betrifft. Testen Sie ihn, bevor ein Benutzer auf die Schaltfläche klicken kann.
9. Schwachstellen in Abhängigkeiten
KI-Tools schlagen Pakete zuversichtlich vor, auch solche, die nicht existieren. Forscher nennen dies “Slopsquatting”: Angreifer registrieren die halluzinierten Paketnamen auf npm oder PyPI und liefern Malware an jeden, der sie installiert. Selbst wenn das Paket existiert, schlägt die KI dazu, alte Versionen mit bekannten CVEs vorzuschlagen. Ihr package.json sieht am Ende wie ein Museum der Schwachstellen des letzten Jahres aus.
Führen Sie eine Abhängigkeitsprüfung für Ihre vollständige Sperrdatei durch: npm audit für Node, pip-audit für Python oder Snyk für beides. Fügen Sie einen CI-Schritt hinzu, der den Build bei schwerwiegenden Funden fehlschlagen lässt. Führen Sie den Scan wöchentlich erneut aus, da ständig neue CVEs für vorhandene Pakete auftauchen.
10. Härtung der Produktionskonfiguration
Die letzten zwanzig Prozent der Probleme vor dem Start liegen in Ihrer Bereitstellungskonfiguration. Die üblichen Verdächtigen sind der Debug-Modus, der immer noch Stack-Traces ausgibt, Source Maps, die neben dem Produktions-JavaScript ausgeliefert werden, Standard-Admin-Anmeldedaten, die niemand geändert hat, und CI/CD-Pipelines, die Geheimnisse in Build-Protokollen preisgeben.
Eine schnelle Checkliste für die Bereitstellungskonfiguration:
- Debug- und ausführliche Fehlermodi deaktiviert.
- Source Maps nicht an den Browser geliefert.
- Alle Standard-Anmeldedaten ersetzt.
- Build-Protokolle von Geheimnissen bereinigt.
- TLS 1.3 überall durchgesetzt.
- Fehlerantworten sind generisch, Details werden nur in internen Protokollen gespeichert.
Diese Liste erscheint offensichtlich gedruckt. Sie deckt auch etwa die Hälfte der peinlichen Vorfälle nach dem Start ab, die auf Hacker News landen. Führen Sie sie vor jedem Deploy aus, nicht nur vor dem Start.
Vibe-Code-Review-Best-Practices: Was zuerst behoben werden sollte
Zehn Prüfungen sind viel, um sie auf einmal zu verarbeiten. Das Schadensprofil ist jedoch ungleichmäßig, und eine Handvoll Probleme verursachen die meisten Sicherheitsverletzungen, die für Schlagzeilen sorgen. Sie können diese zuerst angehen.
Beheben Sie in dieser Reihenfolge:
- Bevor sich ein einziger Produktionsbenutzer anmeldet: offengelegte Geheimnisse (#1), serverseitige Authentifizierung (#2), zeilenbasierte Sicherheit (#3). Diese drei sind für die meisten Schlagzeilen-Sicherheitsverletzungen von 2026 verantwortlich. Drei dieser Prüfungen sind auch die drei, auf die sich unser Team bei einem Audit am meisten konzentriert, da die Fehlerarten nicht wie Bugs aussehen.
- Bevor Zahlungen live gehen: Eingabevalidierung (#4), Ratenbegrenzung (#5), Webhook-Signaturen (#7). Alles, was Geld oder externe Dienste berührt, hängt von allen drei ab.
- Vor Skalierung oder Finanzierungsrunde: Abhängigkeits-Schwachstellen (#9) und Produktionskonfiguration (#10). Investoren und Käufer werden beides bei der technischen Due Diligence prüfen.
- Bevor Sie EU- oder US-Gesundheitsnutzer bedienen: Soft Deletes (#8) und Sicherheits-Header (#6).
KI-Tools machen Code schnell. Die Produktion erfordert eine langsame, überlegte Überprüfung. Für Teams, die eine zweite Meinung bevorzugen, können eine externe Code-Überprüfung und eine vollständige Vibe-Code-Überprüfung das abdecken, was diese Checkliste nicht kann. Wenn das auf Sie zutrifft, sind wir zwei Klicks entfernt und helfen Ihnen gerne weiter.
FAQ
Wie lange dauert ein Vibe-Code-Audit?
Für ein kleines Projekt mit einem Entwickler, einem einzigen Repository und einem engen Funktionsumfang dauert eine strukturierte Erstbewertung ein bis zwei Wochen. Größere oder komplexere Codebasen laufen länger, oft drei bis vier Wochen für eine vollständige Überprüfung. Das Audit selbst ist der schnelle Teil; die Behebung, insbesondere bei Autorisierungs- und Datenbankproblemen, ist, wo der Großteil der Zeit vergeht. Ein abgeschlossenes Audit gibt Ihnen eine priorisierte Liste, Schweregradbewertungen und einen Behebungsplan, den Sie einem Entwickler übergeben können.
Wie unterscheidet sich ein Vibe-Code-Audit von einem Penetrationstest?
Ein Audit liest Ihren Quellcode und sucht nach strukturellen und sicherheitsrelevanten Problemen. Ein Pen-Test greift die laufende Anwendung von außen an und sucht nach dem, was ein tatsächlicher Angreifer finden würde. Die meisten Vibe-Code-Apps benötigen zuerst das Audit, da die Probleme im Code verankert sind und ein Pen-Test nicht alles zeigt, was falsch ist. Führen Sie den Pen-Test nach der Behebung durch, nicht vorher.
Kann ich meinen KI-generierten Code selbst prüfen?
Die zehn obigen Prüfungen erfassen die schädlichsten Probleme, und Sie können die meisten davon mit kostenlosen Tools ausführen. Die kontextabhängigen Probleme sind schwieriger. Geschäftslogikfehler, architektonische Entkopplung und Compliance-Mapping erfordern einen leitenden Ingenieur, der die gleichen Muster in vielen Codebasen gesehen hat. Die meisten Teams entscheiden sich für ein Hybridmodell, bei dem KI-gestützte Code-Überprüfungen die erste Runde übernehmen und ein leitender Ingenieur die letzte Runde.
Was ist das häufigste Problem bei Vibe-Code-Apps?
Deaktivierte zeilenbasierte Sicherheit auf Datenbankebene. Unabhängige Audit-Daten zeigen dies in den meisten mit Lovable erstellten Apps, und das Muster wiederholt sich bei Bolt- und Cursor-Projekten, die von Supabase unterstützt werden. In Kombination mit offengelegten API-Schlüsseln bedeutet dies, dass jeder authentifizierte Benutzer mit wenigen Tastendrücken die Daten jedes anderen Benutzers lesen kann. Es steht ganz oben auf fast jedem Auditbericht, der seinen Namen wert ist, da die Behebung unkompliziert ist und das Risiko erheblich ist.
Sie haben gerade die 10 Prüfungen gelesen. Sehen Sie, wie sie in einem echten Audit aussehen: Über 80 Funde in einer Immobilien-App vor deren Start.
