Lastable — Einblicke

9 Sekunden: was PocketOS über Verantwortung in vibe-engineered Software sagt

Torben Schwellnus — Wed, 29 Apr 2026 00:00:00 GMT

9 Sekunden

Was PocketOS über Verantwortung in vibe-engineered Software sagt

Es dauerte neun Sekunden, bis die Produktionsdatenbank von PocketOS und sämtliche Backups gelöscht waren. Kein Hack. Kein Insider. Kein Stromausfall. Ein Cursor-Agent — angetrieben von Claude Opus 4.6, dem zu diesem Zeitpunkt stärksten verfügbaren Modell — stieß bei einer routinemäßigen Aufgabe auf ein Authentifizierungsproblem, fand in einer fremden Datei einen API-Token mit Admin-Rechten, benutzte ihn, und schaffte das Problem entschlossen aus der Welt: indem er die Datenbank entfernte.

Jeremy Crane, Gründer von PocketOS (Software für Autovermietungen), postete den Vorfall öffentlich auf X. 30 Stunden Ausfall. Älteste wiederherstellbare Sicherung: drei Monate alt. Reservierungen manuell rekonstruiert. Railway-CEO Jake Cooper musste persönlich für eine Recovery eingreifen.

Das ist keine Vibe-Coding-Story

Genau das macht den Vorfall interessant. Bei Moltbook, Tea oder Enrichlead saßen Builder am Steuer, die kein klassisches Engineering-Hintergrund hatten. Bei PocketOS war es ein erfahrener Software-Engineer. Die Plattform war nicht Lovable oder Bolt, sondern Cursor — das Werkzeug der Profis, mit den besten verfügbaren Modellen, mit explizit konfigurierten Sicherheitsregeln. Genau die Konfiguration, die das Vibe-Coding-Problem hätte lösen sollen.

Es hat trotzdem nicht gereicht.

Das ist nicht vibe coding. Das ist vibe engineering — KI-augmentierte Software-Entwicklung durch Menschen mit Engineering-Erfahrung, mit den stärksten Modellen am Markt. Und auch hier ist die Datenbank in neun Sekunden weg.

Die Lücke ist nicht technisch — sie ist organisatorisch

Die strukturelle Frage ist nicht "wie konnte die KI das tun". Sie ist: wer war eigentlich namentlich verantwortlich für die Entscheidung, ob die Datenbank gelöscht werden darf?

In einem klassischen Engineering-Setup hätte ein Senior-Engineer ein Code-Review gemacht, ein DBA hätte eine Migration freigegeben, ein Ops-Verantwortlicher hätte die Deletion gegenzeichnen müssen. Diese Menschen sind nicht aus Bürokratie in der Schleife. Sie sind die Träger der Verantwortung dafür, dass eine zerstörerische Aktion bewusst geschieht.

Wenn der KI-Agent autonom handelt, übernimmt er das Routing. Er übernimmt die Analyse. Was er nicht übernimmt — und nicht übernehmen kann — ist die Verantwortung für eine destruktive Entscheidung in dem Moment, in dem sie getroffen wird. Das ist kein Modell-Fehler. Es ist eine Lücke in der Architektur des Systems.

Cranes eigene Empfehlung nach dem Vorfall ist exakt diese Diagnose: "AI-Agenten sollten zerstörerische Aufgaben nicht ohne Bestätigung ausführen." Was Crane fordert, ist ein DRI-Gate — eine Directly Responsible Individual, eine namentlich benannte Person, die die zerstörerische Entscheidung übernimmt, bevor sie passiert.

Was das mit Vibe Coding zu tun hat

Vibe-Coding-Plattformen wie Lovable und Replit haben dieses Problem in den letzten Monaten verstärkt sichtbar gemacht. Aber PocketOS zeigt, dass die zugrunde liegende Lücke nicht plattform-spezifisch ist. Sie entsteht überall dort, wo autonomie-fähige Agenten ohne explizite menschliche Verantwortlichkeits-Gates arbeiten.

Bei vibe-gecodeten Apps macht die Lücke RLS-Defaults und exponierte Schlüssel teuer. Bei vibe-engineered Apps macht sie 9-Sekunden-Datenbank-Löschungen möglich. Beide haben dasselbe strukturelle Defizit: niemand ist namentlich verantwortlich für die destruktive Entscheidung in dem Moment, in dem sie getroffen wird.

Auch wenn vibe-engineering-Tools und vibe-coding-Platformen es so gut wie jedem ermöglichen, wundervolle Anwendungen und profitable Businesses zu bauen - diese Tools übernehmen nicht die Verantwortung. Es gibt kein Accountability-Toggle-Switch: nicht in Lovables mobile app und es gibt auch kein Verwantwortungs-Skill in claude code oder cursor.

Die Antwort ist nicht "mehr KI-Sicherheit". Die Antwort ist eine organisatorische: ein menschliches DRI-Gate vor jeder zerstörerischen Aktion oder eine klare Delegation der Verantwortung an ein AI Ops Unternehmen. Das ist eine architektonische und organisatorische Entscheidung, keine technische.

Anthropic hat zwei Tage später Claude Opus 4.7 mit verbesserten Safety-Mechanismen für autonome Aufgaben veröffentlicht. Das ist eine richtige Antwort. Es ist nur nicht die einzige Antwort, die fehlt. Es gibt keinen deterministischen Toggle für Accountability. Genau wie in lovable, replit, etc etc.

Was du mitnehmen kannst

Wenn du eine Anwendung in Produktion betreibst — vibe-gecodet oder vibe-engineered — und nicht klar sagen kannst, welcher Mensch namentlich für welche destruktive Aktion verantwortlich ist, fang dort an. Vor jedem Migration-Skript, vor jedem Cleanup-Job, vor jedem Agent-Lauf, der schreibend auf Produktionsdaten zugreift, gehört ein Name.

Du kannst dieses Gate nicht an die Plattform delegieren. Du kannst es nicht an den Agenten delegieren. Du kannst es nur an einen Menschen delegieren — und dieser Mensch muss zum Zeitpunkt der Entscheidung im Loop sein.

Bei Lastable ist genau das Teil unseres Managed-Ops-Modells: jede destruktive Aktion auf Kunden-Infrastruktur hat einen namentlichen Owner und ein Pre-Action-Gate. Das ist nicht sexy. Es verhindert nur 9-Sekunden-Vorfälle. Und es nimmt die Middle-Manager Rolle ein, die dein Unternehmen nicht mehr hat.

Quellen

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

Torben Schwellnus — Tue, 28 Apr 2026 00:00:00 GMT

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 →

Quellen

Wenn 'sicher' nicht sicher genug ist: der Lovable-Vorfall und warum technische Sicherheit nicht reicht

Torben Schwellnus — Fri, 24 Apr 2026 00:00:00 GMT

Wenn "sicher" nicht sicher genug ist

Der Lovable-Vorfall und warum technische Sicherheit nicht reicht

Am 3. März 2026 meldete ein Sicherheitsforscher eine Schwachstelle in Lovables API an HackerOne. Sie war trivial auszunutzen: fünf API-Aufrufe über ein kostenloses Konto genügten, um auf Quellcode, Datenbank-Credentials und KI-Chat-Verläufe fremder Projekte zuzugreifen. Jeder Nutzer. Jedes Projekt, das vor November 2025 angelegt wurde.

Dann passierte: nichts. 48 Tage lang.

Am 20. April ging die Sache öffentlich. Lovables Reaktion verlief in drei Stufen. Erst: Das sei "intended behavior" gewesen — öffentliche Projekte seien schließlich öffentlich. Dann: Die Dokumentation sei vielleicht "unklar" gewesen. Schließlich: Schuld sei HackerOne, deren Triage-Team habe sich an veraltete interne Dokumente gehalten, die genau dieses Verhalten als beabsichtigt beschrieben hätten.

Der Sicherheitsforscher sah das anders. Die Security-Branche sah das anders. Und die Unternehmen, die auf Lovable produktive Apps betreiben, sahen es auch anders.

Ich baue Lastable gerade genau wegen solcher Geschichten. Aber diese hier ist besonders, weil sie keine klassische Breach-Story ist. Es ist eine Geschichte über eine viel grundlegendere Frage: Wer entscheidet eigentlich, was "sicher" ist?

Drei Definitionen von Sicherheit

Wenn du eine vibe-gecodete App in Produktion betreibst, hast du es mit drei Parteien zu tun, die jeweils eine andere Definition von Sicherheit haben. Und nur eine davon zählt für dich — aber es ist nicht die, die am lautesten spricht.

Platform-Sicherheit. Das ist die Lovable-Definition. "Unser System funktioniert wie entworfen." Wenn ein öffentliches Projekt als öffentlich markiert ist, dann ist es öffentlich. Wenn das so gedacht war, dann war es so gedacht. Platform-Sicherheit fragt: Verhält sich die Software wie spezifiziert? Die Antwort kann "ja" sein — und trotzdem kann das Ergebnis katastrophal sein.

Technische Sicherheit. Das ist die Sicht des Forschers. Eine BOLA-Schwachstelle (Broken Object-Level Authorization) liegt vor, wenn ein nicht-autorisierter Akteur auf Daten zugreifen kann, auf die er nicht zugreifen dürfte. Hier ist die Sache eindeutig: fünf API-Aufrufe, fremder Quellcode, fremde DB-Credentials. Technisch ist das ein Textbuch-Fall. Dass Lovable das als "beabsichtigt" einstuft, ändert daran nichts — BOLA ist ein OWASP-API-Security-Top-10-Kriterium, unabhängig davon, ob der Anbieter das Verhalten dokumentiert hat.

Business-Sicherheit. Das ist deine Definition. "Meine Kunden, meine Daten, mein Compliance-Stand sind geschützt." Und hier wird es interessant: diese Definition hat mit den ersten beiden überraschend wenig zu tun. Selbst wenn Platform und Tech beide sauber sind, kannst du ein Business-Sicherheitsproblem haben — wenn die Platform ihre Defaults leise ändert, wenn eine Regression temporär Zugänge öffnet, oder wenn dein Verständnis davon, was "öffentlich" bedeutet, nicht mit dem des Anbieters übereinstimmt.

Im Lovable-Fall haben wir den seltenen Fall, dass alle drei Definitionen kollidieren. Platform-Sicherheit: bestanden (laut Lovable). Technische Sicherheit: glatt durchgefallen. Business-Sicherheit: katastrophal.

Für dich als Betreiber ist nur die dritte relevant. Die ersten beiden sind nicht deine Aufgabe — aber sie bestimmen, ob du die dritte überhaupt erreichen kannst.

⚠️ Beware the tech: Wie die Schwachstelle konkret aussah

Lovables API behandelte Anfragen unterschiedlich, je nachdem wann das Projekt erstellt wurde. Neuere Projekte (nach November 2025) gaben auf denselben Endpunkt ein 403 Forbidden zurück. Ältere Projekte gaben ein 200 OK zurück — inklusive des vollständigen Quellbaums. Die Authorization-Prüfung war für Legacy-Projekte nie korrekt implementiert, und eine Backend-Regression im Februar 2026 hat das Problem nochmals verschärft, indem Chat-Historie und Source-Code auf "öffentlichen" Projekten wieder zugänglich gemacht wurden.

Der Angriffspfad: Auth an der Plattform mit einem beliebigen Free-Account → Nutzer-ID eines fremden Projekts enumerieren → API-Aufruf auf den Projekt-Endpunkt → vollständiger Quellbaum und Credentials. Fünf Calls, keine dokumentierten Rate-Limits.

Das ist kein esoterischer Angriff. Das ist der erste BOLA-Test, den jedes Security-Audit macht.

Warum diese Lücke bleiben wird

Das Lovable-Muster ist nicht die Ausnahme. Es ist strukturell.

Vibe-Coding-Plattformen sind auf Geschwindigkeit optimiert, nicht auf operative Sicherheit. Ihre Kennzahlen messen neue Builder, nicht bestehende Apps. Ihre Roadmaps priorisieren das nächste Feature, nicht das 18-Monats-Patch-Regime für eine App, die du vor einem Jahr gebaut hast. Das ist keine Böswilligkeit — es ist Ökonomie. Die Platform wächst mit Neukunden, nicht mit dauerhaft betreuten Bestands-Apps.

Hinzu kommt ein Problem, das Veracode 2025 quantifiziert hat: 45 % des KI-generierten Codes enthält mindestens eine OWASP-Top-10-Schwachstelle. Wiz hat separat gemessen, dass 20 % aller vibe-gecodeten Apps gravierende Sicherheitslücken mitbringen. Und Q1 2026 zeigte, dass 91,5 % aller vibe-gecodeten Apps mindestens einen halluzinationsbedingten Fehler enthalten.

Du lädst dir also statistisch erwartbar Schwachstellen in den Code, hostest auf einer Platform, die für Ops-Exzellenz keine wirtschaftlichen Anreize hat, und triffst dann auf Vorfälle wie Lovable — wo der Anbieter unter Druck entscheiden kann, dass das beobachtete Verhalten "beabsichtigt" sei.

Das ist keine Platform-Kritik. Es ist eine Arbeitsteilung. Lovable baut Werkzeuge. Für den dauerhaften Betrieb deiner Anwendung ist das Werkzeug nicht zuständig. Die Frage ist nur: wer dann?

Lovable ist kein Einzelfall

Der Lovable-Vorfall ist nur der jüngste in einer Serie, die mittlerweile ein Muster erkennen lässt.

Im Juli 2025 löschte ein Replit-Agent während eines offiziellen Code-Freezes die komplette Produktionsdatenbank eines SaaStr-Projekts — 1.206 Executive-Datensätze, 1.196 Firmen-Datensätze. Der Agent fabrizierte anschließend gefälschte Testergebnisse, um den Vorgang zu verschleiern. Replit-CEO Amjad Masad musste öffentlich reagieren und neue Safeguards ankündigen.

Im August 2025 wurde die Tea-Dating-App gehackt: 72.000 sensible Bilder (darunter 13.000 Ausweisdokumente) und 1,1 Millionen private Nachrichten gelangten auf 4chan. Ursache: ein offener Firebase-Bucket ohne Authentifizierung. Die KI hatte den Upload-Code korrekt generiert — nur ohne die negative Constraint "nicht öffentlich zugänglich machen".

Im März 2026 führte Claude Code ein terraform destroy auf der Produktionsumgebung von DataTalks.Club aus und löschte 2,5 Jahre an Schüler-Daten inklusive aller automatischen Snapshots — 1,94 Millionen Datensätze weg, nur per Amazon-Support wiederhergestellt.

Die Muster wiederholen sich: fehlende Umgebungstrennung, client-seitige Sicherheitslogik, unkonfigurierte Default-Rechte, keine Backups oder nur Backups am selben Ort wie die Produktion, unkontrollierte Agent-Aktionen ohne Delete-Protection. Escape.tech hat 5.600 vibe-gecodete Apps systematisch gescannt und dabei 2.000 Schwachstellen mit hoher Kritikalität, 400 offengelegte Secrets und 175 Fälle exponierter personenbezogener Daten gefunden — in produktiven Systemen. Tenzai hat 15 identische Apps auf fünf verschiedenen Vibe-Coding-Plattformen gebaut und 69 Schwachstellen identifiziert, sechs davon kritisch.

Wenn du all diese Fälle nebeneinanderlegst, fällt auf, dass die Platform-Anbieter in fast allen Vorfällen eine Variante derselben Antwort gegeben haben: "Das System hat wie vorgesehen funktioniert" oder "der Nutzer hätte es anders konfigurieren müssen". Technisch betrachtet mag das stimmen. Geschäftlich ist es kein Trost.

Was ein deutsches Unternehmen jetzt tun muss

Wenn du in Deutschland eine vibe-gecodete App betreibst, hast du zwei Probleme gleichzeitig: ein technisches und ein regulatorisches. Das regulatorische ist kurzfristig das teurere.

DSGVO Art. 32 verlangt von dir eine "geeignete" Absicherung der Verarbeitung. "Lovable hat gesagt, es sei sicher" ist keine rechtliche Verteidigung. Als Verantwortlicher musst du die Sicherheit deines Auftragsverarbeiters eigenständig bewerten — das bedeutet: du brauchst einen AV-Vertrag, eine TOM-Dokumentation und eine eigene Einschätzung der Angemessenheit. Keines dieser Artefakte bekommst du von Lovable standardmäßig mitgeliefert.

DSGVO Art. 33 verpflichtet dich zur Meldung binnen 72 Stunden nach Kenntnis einer Verletzung. Wenn dein Projekt vor November 2025 angelegt wurde und personenbezogene Daten enthält, kann der Lovable-Vorfall für dich ein meldepflichtiger Fall sein — unabhängig davon, ob Lovable ihn als solchen klassifiziert. Dass Lovable ihn "intended behavior" nennt, befreit dich nicht von deiner Prüfpflicht.

Ab August 2026 kommt der EU AI Act obendrauf. Die Bußgeldrahmen addieren sich: DSGVO bis 20 Mio € oder 4 % des Weltumsatzes, AI Act bis 35 Mio € oder 7 %. Die beiden sind unabhängig voneinander durchsetzbar.

Praktisch heißt das:

Wenn deine App vor November 2025 auf Lovable gebaut wurde: heute einen Audit-Trail anlegen, prüfen ob personenbezogene Daten verarbeitet wurden, Art. 33-Prüfung dokumentieren.
Unabhängig vom Erstellungsdatum: prüfen, wo die Daten physisch liegen (Lovable hostet standardmäßig außerhalb der EU), AV-Vertrag einholen, TOMs dokumentieren.
Für jede neue vibe-gecodete App, die produktiv geht: vor dem Go-Live einen unabhängigen Security-Check durchführen lassen. Die Platform macht das nicht für dich.

Das sind nicht meine Empfehlungen. Das ist, was passiert, wenn ein Datenschutzbeauftragter oder ein externer Auditor deine Anwendung bewertet.

Was wir bei Lastable machen

Ich habe Lastable genau deshalb angefangen, weil diese Lücke — zwischen "Platform funktioniert wie entworfen" und "Business ist sicher" — nicht von selbst zugeht. Sie wird größer.

Wir machen einen kostenlosen Health Check für deine vibe-gecodete App: Sicherheitsscan, DSGVO-Bewertung, Hosting-Analyse, Wartungs-Score. PDF-Bericht per E-Mail in fünf Werktagen. Keine Kosten, keine Verpflichtung.

Wenn du danach Hilfe willst bei der Migration auf EU-Hosting oder beim laufenden Betrieb — sind wir da. Wenn nicht, hast du einen Bericht, mit dem du weiterarbeiten kannst, auch ohne uns.

Die ersten 20 Apps bekommen einen Deep-Dive-Audit. Plätze sind noch frei.

Auf die Warteliste →

Quellen

Drei Tage bis zum Aus: was Moltbook über Row-Level-Security lehrt

Torben Schwellnus — Tue, 07 Apr 2026 00:00:00 GMT

Drei Tage bis zum Aus

Was Moltbook über Row-Level-Security lehrt — und warum ich diesen Fehler selbst schon gemacht habe

Im Februar 2026 ging Moltbook online — ein KI-getriebenes soziales Netzwerk, in dem Agenten miteinander interagieren und Nachrichten austauschen. Komplett vibe-gecodet, gestartet mit großem Marketing-Aufwand und einer kleinen, aber lautstarken Beta-Community.

Drei Tage später war es vorbei.

Ein Sicherheitsforscher hatte über die öffentliche API der App auf alle Datensätze zugegriffen: 1,5 Millionen Authentifizierungs-Tokens, 35.000 E-Mail-Adressen, private Nachrichten zwischen Nutzern. Jeder mit dem öffentlichen API-Schlüssel — der bei Supabase-Anwendungen fast immer im Frontend eingebettet und damit weltweit lesbar ist — konnte die komplette Datenbank lesen, schreiben und ändern.

Die Ursache war keine raffinierte Schwachstelle, kein Zero-Day, kein verschachtelter Auth-Bypass. Es war eine einzige, sehr einfache Konfigurationseinstellung, die nie aktiviert wurde: Row-Level-Security auf der Supabase-Datenbank.

Dieser Vorfall ist wichtig, weil er ein Muster offenlegt, das die Marketing-Sprache der Vibe-Coding-Plattformen sorgfältig ausspart: die Default-Konfiguration ihrer empfohlenen Backends ist nicht sicher. Sie ist einfach — was etwas anderes ist. Und der Übergang von "einfach genug zum Anfangen" zu "sicher genug für Produktion" ist niemandes Verantwortung außer deiner.

Wenn du etwas auf Supabase, Firebase oder einem ähnlichen Backend-as-a-Service baust, bist du strukturell der gleichen Falle ausgesetzt wie Moltbook. Hier ist, warum.

Wie Supabase wirklich funktioniert

Supabase ist eine wundervolle Plattform. Sie gibt dir eine PostgreSQL-Datenbank, eine REST-API, Auth, Storage und mehr — alles in wenigen Minuten konfiguriert. Wenn du auf Lovable, Replit oder Bolt baust und eine Datenbank brauchst, ist Supabase oft die erste und naheliegendste Wahl. Die Vibe-Coding-Plattformen schlagen sie standardmäßig vor.

Das Problem: Supabases Standard-Konfiguration vertraut dem Frontend. Jede Abfrage gegen die API wird über einen sogenannten "anon key" authentifiziert — einen Schlüssel, der explizit dafür gedacht ist, im Frontend eingebettet zu sein und damit von jedem im Browser eingesehen werden kann. Dieser Schlüssel hat in der Standard-Einstellung Schreib- und Lesezugriff auf alle Tables.

Damit das funktionieren kann, ohne dass deine ganze Datenbank öffentlich ist, musst du Row-Level-Security (RLS) explizit konfigurieren. RLS sind kleine Policies, die direkt in PostgreSQL leben und für jede Zeile entscheiden: darf der aktuelle Nutzer diese sehen, ändern, löschen?

Wenn RLS deaktiviert ist und du den anon key im Frontend einbettest, ist deine Datenbank im Internet öffentlich. Nicht "im schlimmsten Fall" oder "wenn ein Angreifer einen Bug findet" — sondern strukturell, by design, dokumentiert.

⚠️ Beware the tech: Wie RLS in Supabase wirklich funktioniert

Standard-Verhalten in Supabase: jede neue Tabelle hat RLS deaktiviert. Mit deaktiviertem RLS und einem im Frontend eingebetteten anon key kann jeder im Internet:

alle Datensätze in dieser Tabelle lesen (SELECT * FROM users)

eigene Datensätze einfügen (INSERT INTO users)

bestehende Datensätze ändern (UPDATE users SET ...)

alle Datensätze löschen (DELETE FROM users)

Aktivieren ist trivial: ein Toggle in der Supabase-UI oder ein einzelnes SQL-Statement. Aber nach dem Aktivieren muss du auch noch Policies schreiben — sonst sperrst du dich selbst aus. Eine korrekte Policy für "Nutzer dürfen nur ihre eigenen Daten lesen" sieht so aus:
CREATE POLICY "users_own_data"
ON users FOR SELECT
USING (auth.uid() = user_id);
Das klingt simpel — und ist es auch, wenn du SQL kennst und PostgreSQL-Auth-Konzepte verstehst. Wenn du aber gerade vibe-codest, bist du an einem ganz anderen Punkt deines Workflows: du baust ein Feature, willst es testen, willst, dass die Daten durchfließen. RLS ist die Reibung, die zwischen "Idee" und "es funktioniert" steht.

Ich habe das selbst getan

Ich kenne diesen Punkt aus eigener Erfahrung. Vor einigen Monaten habe ich auf Lovable einen Prototypen gebaut. Supabase hatte ich angeschlossen — der naheliegende Weg, weil Lovable es genau so vorschlägt. Aber bei jedem Versuch, die Row-Level-Security korrekt einzurichten, lief etwas anders als erwartet. Die Policies wurden nicht durchgesetzt, die Login-Session war plötzlich leer, oder eine Abfrage, die im SQL-Editor funktionierte, lieferte über die API plötzlich keine Zeilen zurück.

Nach einem Nachmittag, an dem ich nicht weitergekommen bin, habe ich RLS komplett deaktiviert. Nur kurz, dachte ich, nur um voranzukommen.

Mein Prototyp ist nie öffentlich gegangen — das war von Anfang an die Verabredung mit mir selbst. Es lag nichts Sensibles drin, nichts, was DSGVO-relevant gewesen wäre, und niemand außer mir hatte die URL. Aber genau in diesem Moment habe ich verstanden, warum Moltbook und so viele andere Apps mit deaktiviertem RLS in Produktion landen.

Die Reibung ist echt. Die Frustration ist echt. Und der Schritt von "kurz mal deaktivieren, um voranzukommen" zu "ich vergesse, es wieder einzuschalten, weil mir niemand sagt, dass es noch aus ist" ist sehr klein. Wenn du es zwei Wochen später irgendwann in Produktion deployst, fragt dich keine Plattform: "Übrigens, RLS ist auf vier Tables deaktiviert — willst du das wirklich so live nehmen?"

Das ist kein Entwicklerfehler. Es ist ein Plattform-Fehler. Das System lässt einen Zustand zu, in dem die einzige verbleibende Schutzschicht zwischen deinen Nutzerdaten und dem öffentlichen Internet eine Konfigurationsoption ist, die du in einem hektischen Moment deaktiviert und nie wieder bewusst geprüft hast.

Warum das Muster überall ist

Wenn du nach "Supabase RLS not working" googelst, findest du tausende Stack-Overflow-Posts, Reddit-Threads und Discord-Diskussionen. Das gleiche Muster: Jemand will RLS aktivieren, eine Policy schreiben, eine Abfrage testen — und es funktioniert nicht wie erwartet. Daten kommen nicht durch. Login bricht. Build schlägt fehl.

Die Standard-Antworten in den Diskussionen: "Du musst dafür dieses und jenes konfigurieren." "Hast du den Service-Role-Key statt des Anon-Key benutzt?" "Hast du auth.uid() in deiner Policy?" "Cache eine Stunde lang invalidieren und dann erneut testen." Für jeden Schritt, den du verstehen musst, bevor RLS funktioniert, gibt es Vibe-Coder, die abbrechen und stattdessen RLS deaktivieren — explizit oder durch Workarounds wie USING (true)-Policies, die exakt nichts schützen.

Die Plattformen verschärfen das Problem. Lovable und Replit erwähnen RLS in ihrer KI-generierten Anleitung manchmal, aber nicht durchgängig. Sie testen nicht, ob es aktiviert ist. Sie warnen nicht, wenn deine App live geht und RLS noch deaktiviert ist. Sie unterscheiden nicht zwischen Prototyp und Produktion.

Damit bleibt das Risiko vollständig beim Builder hängen — also bei der Person, die am wenigsten Erfahrung mit Datenbank-Sicherheit hat, weil sie ja gerade auf eine Plattform setzt, die ihr genau diese Erfahrung ersparen sollte. Es ist eine Verantwortungs-Verteilung, die nicht funktioniert.

Die Zahlen bestätigen das. Eine Q1-2026-Untersuchung von über 200 vibe-gecodeten Anwendungen hat gezeigt, dass mehr als 60 % davon API-Schlüssel oder Datenbank-Credentials in öffentlichen Repositories oder Frontend-Bundles offenlegen. Eine breit angelegte Scan-Analyse von 5.600 öffentlich erreichbaren vibe-gecodeten Apps fand 2.000 hochkritische Schwachstellen, 400 offengelegte Secrets und 175 Fälle von exponierten personenbezogenen Daten — inklusive Gesundheitsdaten und Zahlungsinformationen.

Das ist kein Anti-Pattern. Das ist das Standard-Verhalten.

Was Moltbook gerettet hätte

Nicht ein Audit nach dem Vorfall. Auch nicht ein Audit eine Woche vor dem Launch — denn da war RLS in der Architektur schon nicht aktiv, und niemand hat es bemerkt.

Was Moltbook gerettet hätte, ist eine Routine: ein automatischer Pre-Launch-Check, der genau einen einzigen Punkt prüft — "sind alle Tables in der angeschlossenen Supabase-Instanz mit aktivem RLS und mindestens einer sinnvollen Policy konfiguriert?" Eine Checkliste, die für jede vibe-gecodete App vor dem Go-Live durchläuft. Drei Minuten Arbeit, ein klarer rot/grün-Bericht.

Genau das machen wir bei Lastable. Unser Full Technical Health Check prüft RLS-Status, Storage-Bucket-Sicherheit, exponierte Schlüssel im Frontend, fehlende Auth-Konfiguration auf Standard-Endpunkten.

Wenn du gerade eine Lovable-, Replit- oder Bolt-App in Produktion stellst und nicht hundertprozentig sicher bist, ob RLS oder vergleichbare Mechanismen aktiv sind, dauert der Quickscan auf lastable.dev genau 30 Sekunden für eine erste Einschätzung. Der einzige Preis: vielleicht musst du danach drei Stunden investieren, um zu reparieren, was du gefunden hast.

Aber das ist günstiger als drei Tage.

Quickscan starten →