Vibe Coding Security: Warum 45 % des AI-generierten Codes unsicher ist

Du hast in wenigen Stunden eine funktionierende App gebaut. Mit Lovable, Bolt, Cursor oder einem anderen AI-Tool. Das Frontend sieht gut aus, das Backend antwortet, die Datenbank speichert. Du denkst: fertig.

Aber hast du dich mal gefragt, ob dein Code sicher ist?

Nicht "sicher" im Sinne von "funktioniert ohne Absturz". Sondern sicher im Sinne von: Kann jemand auf die Daten deiner Nutzer zugreifen? Kann jemand deine Datenbank manipulieren? Kann jemand deine App missbrauchen?

Die kurze Antwort: Wahrscheinlich ja. Und das ist kein Vorwurf an dich. Das liegt am Werkzeug.

Die Zahlen sind eindeutig

Vibe Coding — also das Bauen von Software durch natürlichsprachige Anweisungen an eine AI — ist seit Anfang 2025 einer der größten Trends in der Softwareentwicklung. Der Begriff wurde von AI-Forscher Andrej Karpathy geprägt und beschreibt einen Workflow, bei dem du der AI sagst was du willst und sie den Code schreibt.

Das funktioniert erstaunlich gut. Aber "funktioniert" und "ist sicher" sind zwei verschiedene Dinge.

Hier die Fakten:

45 % des AI-generierten Codes enthält Sicherheitslücken. Das ergab der GenAI Code Security Report 2025 von Veracode — eines der größten Application-Security-Unternehmen weltweit. Fast jede zweite Zeile, die eine AI schreibt, hat ein Sicherheitsproblem.

69 Schwachstellen in 15 Apps. Die Sicherheitsfirma Tenzai hat im Dezember 2025 fünf der populärsten Vibe-Coding-Tools getestet — darunter Cursor, Replit und Codex. Jedes Tool sollte drei identische Web-Apps bauen. Das Ergebnis: 69 Schwachstellen, davon etwa ein halbes Dutzend als "kritisch" eingestuft.

2,74-mal höhere Fehlerrate. Eine Analyse von CodeRabbit (Dezember 2025) über 470 Open-Source Pull Requests auf GitHub zeigte: AI-geschriebener Code hat eine fast dreimal höhere Rate an Sicherheitslücken als Code von menschlichen Entwicklern.

0 von 15 getesteten Apps hatten Security-Headers. Keine einzige der von Tenzai getesteten Vibe-Coding-Apps implementierte grundlegende Schutzmechanismen wie CSRF-Schutz oder Sicherheits-Header. Null.

170 von 1.645 Lovable-Apps hatten offene Daten. Im Mai 2025 wurde bekannt, dass über 10 % der öffentlich zugänglichen Lovable-Apps eine Schwachstelle hatten, über die persönliche Daten frei zugänglich waren.

Das sind keine theoretischen Risiken. Das sind gemessene Probleme in echten Apps, die echte Menschen gebaut haben.

Die 5 häufigsten Sicherheitslücken in vibe-gecodeten Apps

Du musst kein Entwickler sein, um zu verstehen, was hier schiefläuft. Die meisten Probleme lassen sich in fünf Kategorien zusammenfassen.

1. Offene Datenbank-Zugriffe

Die meisten AI-Tools setzen auf Supabase als Datenbank. Supabase hat ein Feature namens Row Level Security (RLS) — das bestimmt, wer auf welche Daten zugreifen darf. Das Problem: AI-Tools konfigurieren RLS oft falsch oder gar nicht.

Das bedeutet: Jeder, der die URL deiner Supabase-Instanz kennt, kann theoretisch alle Daten lesen. Nutzerdaten, E-Mails, Passwörter, alles.

Stell dir vor, du lässt die Haustür deines Ladens offen — aber hängst ein Schild dran mit "Bitte nicht reinkommen". Technisch ist die Tür offen. Dass niemand reingeht, ist reine Glückssache.

2. Fehlende Authentifizierung und Autorisierung

Authentifizierung prüft, ob ein Nutzer der ist, der er vorgibt zu sein. Autorisierung prüft, ob dieser Nutzer das tun darf, was er gerade versucht.

AI-generierter Code implementiert oft nur die Hälfte: Der Login funktioniert, aber dahinter gibt es keine Prüfung. Ein angemeldeter Nutzer kann auf Daten anderer Nutzer zugreifen, Admin-Funktionen aufrufen oder Daten verändern, die er nicht verändern sollte.

3. Server-Side Request Forgery (SSRF)

Klingt technisch, ist aber einfach erklärt: Dein Server lässt sich dazu bringen, Anfragen an interne Systeme zu schicken, die von außen nicht erreichbar sein sollten.

Die Tenzai-Studie stellte fest: Jedes einzelne getestete Vibe-Coding-Tool erzeugte SSRF-Schwachstellen. Ausnahmslos.

4. Hardcoded Secrets

API-Keys, Datenbank-Passwörter, Zugangsdaten für Dienste wie Stripe oder SendGrid — AI-Tools schreiben diese Informationen gerne direkt in den Quellcode. Statt sie in geschützten Umgebungsvariablen zu speichern, stehen sie im Code. Für jeden lesbar, der Zugang zum Repository hat.

Das ist, als würdest du den Tresorcode auf einen Zettel schreiben und ihn an den Tresor kleben.

5. Fehlende Security-Headers und CSRF-Schutz

Security-Headers sind Anweisungen, die dein Server an den Browser schickt: "Lade keine Skripte von fremden Seiten", "Erlaube kein Einbetten in iFrames", "Erzwinge HTTPS". Sie sind eine grundlegende Verteidigungslinie.

CSRF-Schutz verhindert, dass jemand eine Aktion in deiner App auslöst, indem er einen Nutzer auf eine manipulierte Seite lockt.

Beides fehlt in AI-generiertem Code fast immer. Nicht manchmal. Fast immer.

Warum AI-Tools das nicht selbst fixen

Vielleicht denkst du jetzt: "Dann sage ich der AI halt, sie soll den Code sicher machen." Das klingt logisch — funktioniert aber nicht zuverlässig. Aus drei Gründen.

AI optimiert auf "funktioniert", nicht auf "ist sicher"

Wenn du einem AI-Tool sagst "Baue mir eine App mit Login und Datenbank", dann bewertet das Tool seinen eigenen Erfolg danach, ob die App funktioniert. Nicht danach, ob sie sicher ist. Sicherheit ist kein Feature, das du siehst. Es ist die Abwesenheit von Problemen — und das ist etwas, das AI schlecht misst.

AI kennt deinen spezifischen Kontext nicht

Sicherheit hängt vom Kontext ab. Verarbeitet deine App Gesundheitsdaten? Finanzdaten? Daten von Minderjährigen? Jeder Fall hat andere Anforderungen. AI-Tools kennen diesen Kontext nicht und treffen deshalb generische Entscheidungen, die im besten Fall unvollständig und im schlimmsten Fall falsch sind.

Der Circular Bug Cycle

Du meldest ein Sicherheitsproblem. Die AI fixt es — und erzeugt dabei ein neues. Du meldest das neue. Die AI fixt es und bricht etwas anderes. Dieser Kreislauf ist kein Randphänomen. Es ist der Normalfall, wenn man komplexe Sicherheitsprobleme durch Prompts zu lösen versucht.

Sicherheit ist kein Feature, das man nachträglich reinprompten kann. Sie muss verstanden, geplant und systematisch umgesetzt werden. Dafür braucht es einen Menschen, der weiß, was er tut.

Was das für dich konkret bedeutet

Wenn du mit Lovable, Bolt, Cursor oder einem ähnlichen Tool eine App gebaut hast und planst, sie echten Nutzern zugänglich zu machen, gibt es drei Szenarien:

Szenario 1: Deine App verarbeitet keine sensiblen Daten. Kein Login, keine persönlichen Informationen, kein Payment. In dem Fall ist das Risiko überschaubar — aber selbst dann können offene API-Endpunkte oder fehlende Rate-Limits Probleme verursachen.

Szenario 2: Deine App hat Nutzerkonten. Sobald sich jemand registriert und Daten hinterlegt, bist du verantwortlich. In Deutschland greift die DSGVO — und die unterscheidet nicht zwischen einer App von Google und einer App, die du an einem Sonntagnachmittag mit Lovable gebaut hast. Datenschutzverletzungen können teuer werden.

Szenario 3: Deine App verarbeitet Zahlungen oder sensible Daten. Hier ist die Schwelle am höchsten. Stripe-Integration, Gesundheitsdaten, Verträge — ein Sicherheitsproblem in diesem Bereich kann dein Geschäft ruinieren, bevor es richtig angefangen hat.

Was du tun solltest, bevor du live gehst

Die gute Nachricht: Du musst kein Sicherheitsexperte werden. Du musst nur wissen, dass du einen brauchst. Hier eine Checkliste — nicht technisch, sondern als Orientierung.

Authentifizierung prüfen lassen. Funktioniert der Login wirklich? Kann ein Nutzer auf Daten zugreifen, die ihm nicht gehören? Sind Admin-Bereiche geschützt?

Datenbank-Zugriffe prüfen lassen. Sind Supabase RLS-Policies korrekt konfiguriert? Kann jemand von außen auf Tabellen zugreifen, die intern sein sollten?

Secrets aus dem Code entfernen. API-Keys, Passwörter und Tokens gehören in Umgebungsvariablen — nicht in den Quellcode. Ein Entwickler findet und behebt das in Minuten.

Security-Headers setzen lassen. Content-Security-Policy, X-Frame-Options, Strict-Transport-Security — klingt komplex, ist für einen Entwickler Standardarbeit.

DSGVO-Grundlagen prüfen. Wo werden Daten gespeichert? Gibt es eine Datenschutzerklärung? Können Nutzer ihre Daten löschen lassen? Werden Einwilligungen korrekt eingeholt?

Einen professionellen Code-Review machen lassen. Nicht durch eine AI. Durch einen Menschen, der den Code liest, versteht und systematisch prüft. Das dauert ein bis zwei Tage und gibt dir Klarheit über den tatsächlichen Zustand deiner App.

Vibe Coding ist nicht das Problem. Fehlende Prüfung ist es.

Lass mich klar sein: Ich bin kein Gegner von Vibe Coding. Tools wie Lovable, Bolt und Cursor sind beeindruckend und sie demokratisieren Softwareentwicklung auf eine Art, die vor zwei Jahren undenkbar war.

Aber sie ersetzen nicht das Handwerk. Sie ersetzen nicht das Verständnis dafür, was zwischen "funktioniert auf meinem Bildschirm" und "ist sicher für tausend Nutzer" liegt. Die AI baut den Rohbau. Aber den TÜV macht sie nicht.

Wenn du eine App gebaut hast, auf die du stolz bist — dann lass sie prüfen, bevor du sie der Welt zeigst. Nicht weil sie schlecht ist. Sondern weil sie es verdient, gut abgesichert zu sein.