SecurityDSGVOAnalyseSelf-AssessmentPattern

Die 5 Sicherheitsfehler, die fast jede vibe-gecodete App teilt

Veröffentlicht am 28. April 2026 · 9 min Lesezeit · von Torben Schwellnus

Die 5 Sicherheitsfehler, die fast jede vibe-gecodete App teilt

Vibe Coding hat eine Reihe von wiederkehrenden Sicherheitsmustern produziert, die so hartnäckig sind, dass sie inzwischen fast als Plattform-Eigenschaft durchgehen. Ich habe die letzten Monate damit verbracht, öffentlich dokumentierte Vorfälle zu katalogisieren — von Moltbook über Tea, Enrichlead und DataTalks bis zum Lovable-Vorfall vom April — und in fast jedem Fall lassen sich die Ursachen auf eine sehr kleine Liste zurückführen.

Diese fünf Fehler sind nicht exotisch. Sie sind nicht neu. Sie sind nicht einmal spezifisch für KI-generierten Code. Aber sie tauchen in vibe-gecodeten Apps so zuverlässig auf, dass sie ein eigenes Genre verdient haben.

Wenn du eine vibe-gecodete App in Produktion betreibst — oder gerade dabei bist, sie dorthin zu bringen — geh diese Liste durch. Jeder Punkt enthält einen 60-Sekunden-Selbst-Test. Wenn auch nur einer rot anschlägt, hast du Arbeit vor dir.

Fehler 1 — Default-Public-Datenbanken

Die meisten vibe-gecodeten Apps verwenden Supabase, Firebase oder MongoDB Atlas als Backend. Das ist eine vernünftige Wahl — diese Plattformen sind großartig dokumentiert und in wenigen Minuten einsatzbereit. Lovable, Replit und Bolt schlagen sie standardmäßig vor.

Das Problem: ihre Default-Konfigurationen sind dafür gedacht, dir den Einstieg zu erleichtern, nicht deine Daten zu schützen. Bei Supabase ist Row-Level-Security (RLS) auf neuen Tabellen standardmäßig deaktiviert. Bei Firebase erlauben die Default-Security-Rules in der Entwicklungsumgebung typischerweise jeden authentifizierten Zugriff — was bedeutet, dass jeder, der sich einen kostenlosen Firebase-Account anlegt, lesen und schreiben kann. Bei MongoDB Atlas Free-Tier-Clustern war "no auth required" jahrelang Default.

Diese Konfigurationen sind nicht falsch dokumentiert. Sie sind explizit beschrieben. Aber wenn du vibe-codest, übernimmst du den Default, weil dein KI-Tool ihn übernommen hat — und beide haben gerade keine Lust, eine Berechtigungs-Strategie zu entwerfen. Welcome to vibe-coding crystal meth ;-)

Moltbook ging genau daran kaputt: RLS war nie aktiviert, der anon key lag im Frontend, jeder konnte alles. Drei Tage live, dann vorbei.

✓ Selbst-Test in 60 Sekunden — Datenbank-Defaults

Öffne dein Supabase- / Firebase- / MongoDB-Dashboard. Ist RLS bzw. sind Security Rules auf jeder produktiv genutzten Tabelle aktiv?

Wenn ja: hast du Policies geschrieben, die echte Bedingungen prüfen — nicht USING (true) oder allow read: if true?

Öffne in einem privaten Browserfenster die öffentliche API deiner App und versuche, ohne Login auf User-Daten zuzugreifen. Wenn das geht, hast du den Fehler.

Fehler 2 — Sicherheitslogik im Frontend

KI-Tools generieren Code, der funktioniert. Sie generieren selten Code, der gegen Manipulation geschützt ist.

Das klassische Muster: deine App hat einen Premium-Bereich. Im Frontend wird geprüft "hat der Nutzer ein Premium-Abo?" und wenn ja, der Bereich angezeigt. Im Backend wird die gleiche Prüfung nicht durchgeführt — der Server liefert die Daten an jeden, der danach fragt.

Das gleiche gilt für Authorization: wenn deine "darf dieser Nutzer das?"-Logik nur im JavaScript-Bundle steckt und nicht serverseitig auf jedem Endpunkt durchgesetzt wird, kann ich deine API ohne korrekte Berechtigung aufrufen. Browser-Konsole öffnen, fetch() schreiben, fertig.

Enrichlead war drei Tage live, bevor Nutzer per Browser-Konsole das Paywall umgangen haben. Die Bezahllogik lag komplett im Frontend. Der Lovable-Vorfall im April folgte demselben Muster auf Plattform-Ebene: die Authorization-Prüfung wurde für Legacy-Projekte serverseitig nicht durchgesetzt. Fünf API-Aufrufe genügten, um auf fremden Sourcecode zuzugreifen.

Das Genre wird ergänzt durch API-Schlüssel im Frontend. Wenn dein Stripe-Live-Key, deine OpenAI-Credentials oder dein Service-Role-Key irgendwo im Frontend-Bundle landen (das passiert in vibe-coded apps fast standardmäßig), dann hat jeder, der sich die Mühe macht, den Bundle anzuschauen, sie auch.

✓ Selbst-Test in 60 Sekunden — Frontend-Logik

Öffne deine App in einem privaten Browserfenster, drück F12 → Network-Tab.

Klick auf eine geschützte Funktion. Schau dir die API-Anfrage an. Kopiere die URL und führe sie ohne Authentication-Header aus (z.B. mit curl). Wenn die Daten kommen, hast du den Fehler.

Such im JS-Bundle nach sk_live_, AKIA, AIza, ghp_ oder service_role. Hits = Problem.

Fehler 3 — Fehlende Trennung zwischen Test und Produktion

Vibe-Coding-Plattformen geben dir per Default eine einzige Umgebung. Es gibt nicht Dev, Staging und Production — es gibt nur "die Lovable-App, an der du baust". Wenn du sie live machst, ist genau diese App live. Wenn du sie änderst, änderst du die Live-Version.

Das Problem zeigt sich auf zwei Arten.

Erstens: Daten. Wenn du beim Bauen Test-User anlegst, Test-Inhalte einfügst, Test-Zahlungen durchspielst — all das landet in derselben Datenbank wie deine Live-User. Wenn du die App startest, müssen die Test-Daten gelöscht werden, ohne dass die Live-Daten danach beschädigt sind. Das passiert in der Praxis selten sauber.

Zweitens: KI-Agenten mit Schreibzugriff. Wenn du Claude Code, Cursor oder Replit-Agents Zugriff auf dein Repository und deine Infrastruktur gibst, hat der Agent oft Zugriff auf produktive Ressourcen. Bei DataTalks.Club hat Claude Code im März 2026 ein terraform destroy ausgeführt, das 2,5 Jahre Produktionsdaten inklusive aller automatischen Snapshots gelöscht hat — 1,94 Millionen Datensätze, nur per Amazon-Support teilweise wiederhergestellt. Bei SaaStr hat ein Replit-Agent während eines deklarierten Code-Freezes die komplette Datenbank geplättet und anschließend gefälschte Test-Ergebnisse fabriziert, um den Vorfall zu "verdecken". Agents like to please..

Was beide Fälle gemeinsam haben: keine echte Trennung zwischen Agenten-Spielwiese und Produktion, keine Delete-Protection, Backups in derselben Cloud-Region und somit im gleichen Blast-Radius.

✓ Selbst-Test in 60 Sekunden — Umgebungen

Hat deine App separate Datenbanken für Test und Produktion?

Wenn nein: kannst du die Live-DB versehentlich löschen, indem du im Editor "Reset DB" klickst?

Hast du Backups, die NICHT in derselben Cloud-Region und unter denselben Credentials liegen wie die Produktion?

Hat dein KI-Agent die Berechtigung, produktiv schreibend zuzugreifen — und falls ja, gibt es Delete-Protection?

Fehler 4 — Storage-Buckets ohne Auth

Wenn deine App Bilder, Dokumente oder Dateien speichert, hängt sie an einem Storage-Bucket bei Firebase Storage, Supabase Storage, Cloudflare R2 oder Amazon S3. Diese Buckets haben ihre eigene Permission-Schicht, die unabhängig von der Datenbank-Auth läuft. Das vergisst die KI fast immer.

Wenn der KI-Agent dir den Upload-Code schreibt, schreibt er die Datei in den Bucket und konfiguriert die Bucket-Permissions auf "public read". Weil das beim Testen funktioniert. Weil beim Testen niemand fragt: "müssen alle Nutzer alle Dateien sehen können?"

Tea, eine Dating-App speziell für Frauen, hatte 72.000 sensible Bilder — darunter 13.000 staatliche Ausweisdokumente — und 1,1 Millionen private Nachrichten auf 4chan, weil der Firebase-Bucket öffentlich war. Die KI hatte den Upload-Code korrekt geschrieben — sie hatte nur die negative Constraint "nicht öffentlich machen" nicht im Prompt gehabt. Der Vorfall ist mittlerweile Lehrbeispiel für genau dieses Muster.

Hinzu kommt: Storage-URLs sind oft enumerierbar. Wenn deine Datei https://your-bucket.firebase.app/uploads/user-1234/profile.jpg heißt, sind die URLs für user-1235, user-1236 ... ratbar. Selbst wenn der Bucket nicht offen verzeichnis-listet, kann ich seine Inhalte erschließen.

✓ Selbst-Test in 60 Sekunden — Storage

Lade eine Datei in deine App hoch. Kopiere die URL der Datei.

Öffne die URL in einem privaten Browserfenster ohne Login. Wenn die Datei lädt: Fehler.

Versuche, einen Buchstaben in der URL zu ändern (Datei-ID oder User-ID-Pfad). Wenn andere Dateien laden: noch größerer Fehler.

Fehler 5 — Eingefrorene Dependencies

Vibe-Coding-Plattformen erstellen deinen Code mit einem Snapshot von Bibliotheken zum Zeitpunkt des Builds. Lovable, Replit und Bolt frieren package.json / requirements.txt mit den Versionen ein, die der KI-Agent zu diesem Zeitpunkt für richtig gehalten hat.

Niemand updated diese Dependencies danach. Es gibt keinen Plattform-Mechanismus, der monatlich npm audit oder pip-audit auf deinem Code laufen lässt und dich warnt, wenn eine deiner Bibliotheken eine bekannte CVE bekommen hat. Es gibt keinen automatischen Pull-Request, der eine Sicherheitsaktualisierung vorschlägt. Es gibt nicht einmal eine E-Mail.

Damit altert deine vibe-gecodete App, sobald sie online ist. Der Veracode 2025 State of Software Security Report fand, dass 45 % des KI-generierten Codes mindestens eine OWASP-Top-10-Schwachstelle enthält. Eine Q1-2026-Untersuchung zeigte, dass 91,5 % aller vibe-gecodeten Apps mindestens einen halluzinationsbedingten Fehler enthalten. Beides sind Befunde im Code zum Zeitpunkt der Erstellung. Und code-libraries altern gar nicht gut. Jede nicht mitgenommener Versionssprung ist ein Chance mehr, dass die vibe-gecodete App anfällig ist, für ein Sicherheits-Exploit.

Georgia Tech's Vibe Security Radar hat im März 2026 allein 35 neue CVEs registriert, die direkt durch KI-generierten Code verursacht wurden. Im Januar waren es noch sechs.

✓ Selbst-Test in 60 Sekunden — Dependencies

Wann wurden zuletzt Dependencies in deinem Repository aktualisiert? (Schau ins git-log oder in die Mtime von package-lock.json / requirements.txt.)

Wenn die Antwort "beim Build" ist: hast du Glück, falls keine kritische CVE in einer deiner Bibliotheken in den letzten Monaten gefunden wurde.

Liste deine fünf wichtigsten direkten Dependencies und google jede + "CVE 2026". Wenn da was zurückkommt, dann weisst Du zumindest schonmal, was Du heute noch vorhast.

Was diese fünf gemeinsam haben

Auf den ersten Blick haben die Fehler wenig miteinander zu tun: ein Datenbank-Toggle, ein Frontend-Pattern, ein Umgebungs-Konzept, ein Bucket-Default und ein Patch-Regime. Aber sie folgen alle derselben strukturellen Logik.

Die Plattform liefert dir Werkzeuge, die per Default für "einfacher Einstieg" optimiert sind. Der KI-Agent generiert Code, der per Default für "es funktioniert sofort" optimiert ist. Du selbst bist die einzige Schicht, die zwischen "es funktioniert" und "es ist sicher" steht.

Das ist eine Position, in die niemand freiwillig kommt. Du hast vibe-gecodet, weil du nicht erst zwei Wochen Datenbank-Sicherheit, Cloud-Permissions und Dependency-Management lernen wolltest, bevor du deine Idee testen konntest. Genau dieser Wunsch wird jetzt zum Risiko.

Die einfache Wahrheit: keine der fünf Fehler ist schwer zu beheben. Aber sie alle erfordern, dass jemand sie aktiv prüft. Die Plattformen tun das nicht. Die KI-Agenten tun das nicht. Die Default-Tools für vibe-gecodete Apps haben für genau dieses Problem keine Antwort.

Was wir bei Lastable machen

Wir bauen genau diese Schicht — den Layer zwischen "KI-generierter Code" und "sicherer Produktivbetrieb". Unser Full Technical Health Check prüft alle fünf Fehler aus dieser Liste und gibt dir einen klaren Bericht, was du selbst beheben kannst und wo wir helfen würden. Der kostenlose Quickscan schaut schonmal nicht-invasiv von aussen drüber, um einen ersten Eindruck zu bekommen.

Kein Account nötig, keine versteckten Kosten, kein automatisches Verkaufsgespräch.

Wenn der Quickscan rote Punkte findet, hast du zwei Optionen: selbst reparieren oder mit uns reden. Beide sind in Ordnung, dann macht vibe-coden auch wieder Spass, auch in Zukunft.

Quickscan starten →