Eine App per Textbefehl bauen, ohne eine Zeile Code zu verstehen: Das ist das Versprechen von Vibe Coding und Plattformen wie Lovable. Ein Bericht des Handelsblatts vom 2. November 2026 zeigt, was passiert, wenn danach niemand auf Konfiguration und Updates schaut. Dieser Beitrag ordnet den Fall für Unternehmen und Selbstständige in Heidelberg, Wiesloch und Rhein-Neckar ein und zeigt, was zum sicheren Betrieb einer solchen App gehört.
Auf einen Blick
- Der Fall: Laut Handelsblatt konnte ein IT-Sicherheitsexperte bei etwa 15 Prozent von über 140.000 untersuchten deutschsprachigen Lovable-Seiten Daten einsehen, darunter Ausweisdaten und Anmeldedaten von Nutzern.
- Die Ursache: fehlende oder fehlerhafte „Row Level Security“ (RLS) in der Datenbank beim Backend-Anbieter Supabase, also ein Konfigurationsfehler, kein Hackerangriff.
- Die Verantwortung: Lovable spricht von „geteilter Verantwortung“. Die Betreiber der Seiten müssen selbst handeln, auch wenn sie keine Entwickler sind.
- Die Lehre: Eine App zu bauen ist mit KI schnell erledigt. Sie sicher zu betreiben, also Konfiguration prüfen, Updates einspielen und auf Sicherheitsmeldungen reagieren, bleibt Arbeit.
Was ist bei Lovable passiert?
Das Handelsblatt berichtet Link: Handelsblatt-Artikel (Paywall) über Analysen des IT-Sicherheitsexperten Thomas Jansen. Er bemerkte das Problem zuerst auf der Lovable-Seite eines Bekannten: Über einen normalen Browser konnte er die E-Mail-Adressen der angemeldeten Nutzer sehen. Danach suchte er gezielt im Code von Lovable-Seiten nach öffentlichen Schlüsseln und prüfte, was sich damit abrufen lässt.
Nach eigenen Angaben untersuchte Jansen mehr als 140.000 deutschsprachige Lovable-Seiten und konnte bei etwa 15 Prozent Daten einsehen. Als Beispiele nennt das Handelsblatt eine Seite für US-Visa-Anträge mit Namen, Geburtstagen und Passnummern, zeitweise sogar Fotos von Ausweisen, sowie eine Radio-Webseite mit Profilen registrierter Nutzer. Für die Analyse brauchte er laut eigener Aussage dank KI „vielleicht fünf Stunden“. Insgesamt fand er nach eigenen Angaben mehr als 20.000 betroffene Lovable-Nutzer.
Wichtig für die Einordnung: Jansen hat sich nirgends eingehackt. Der vom Handelsblatt befragte Ethical Hacker und IT-Rechtsexperte Dirk Koch sagt, Jansen habe einen Schlüssel genutzt, der von vornherein für die Öffentlichkeit bestimmt ist: „Wer ihn verwendet, knackt kein Passwort und umgeht keinen Schutz, sondern nutzt den Zugang, den die Seite selbst jedem bereitstellt.“
Was hat RLS bei Supabase damit zu tun?
Die betroffenen Seiten nutzen Supabase als Backend, also für Datenbank und alles, was hinter der Oberfläche passiert. Im Code der Seite steckt ein sogenannter Anon-Key, ein öffentlicher Zugangsschlüssel. Er ist dafür gedacht, Besuchern das zu zeigen, was jeder sehen darf. Auf sensible Daten sollte er keinen Zugriff erlauben.
Ob er das tut, entscheidet die Row Level Security (RLS): Regeln in der Datenbank, die pro Tabelle und Zeile festlegen, wer was lesen und ändern darf. Fehlen diese Regeln oder sind sie falsch gesetzt, reicht der öffentliche Schlüssel, um ganze Tabellen abzurufen.
Lovables Sicherheitschef Igor Andriushchenko nennt fehlende oder fehlerhafte RLS gegenüber dem Handelsblatt „ein bekanntes, branchenweit verbreitetes Konfigurationsproblem und kein spezifisches Problem von Lovable“. Auch Jansen und Koch gehen davon aus, dass andere Anbieter betroffen sind. Laut Handelsblatt zeigte ein Bericht der Sicherheitsforscher von Upguard Anfang Oktober Ähnliches für weitere Seiten, die mit KI-Werkzeugen und Supabase gebaut wurden.
Supabase erklärt laut Handelsblatt, RLS sei standardmäßig aktiv. Neue Projekte gäben seit Ende Mai 2026 keine Tabellen mehr über öffentliche Zugänge preis, ab Ende Oktober solle das für alle Projekte gelten. Ein Hinweis von Matt Palmer an Lovable auf genau diese Fehlkonfigurationen stammt bereits aus dem März 2025.
Warum ist „es geht einfach alles“ nur die halbe Wahrheit?
Lovable hat nach eigener Aussage im April 2025 Sicherheitsscanner veröffentlicht und informiert Nutzer über Lücken. Die meisten von Jansen untersuchten Seiten entstanden laut Handelsblatt aber erst Monate danach. In drei Beispielfällen, die das Handelsblatt Lovable vorlegte, hatte Lovable die Betreiber nach eigener Aussage informiert. Diese hätten jedoch „vor der Veröffentlichung keine entsprechenden Maßnahmen ergriffen“.
Andriushchenko fasst es so zusammen: „Sicherheit ist eine geteilte Verantwortung.“ Die Entwickler seien für die Verwendung verantwortlich, „genau wie bei jedem Softwareprojekt“. Das Handelsblatt hält dagegen: Die meisten Lovable-Nutzer sind keine Entwickler, und Lovable verspricht gerade, dass sie mit Backends, Anon-Keys oder Datenbanken nicht umgehen können müssen.
Genau hier liegt das Risiko von Vibe Coding. Die KI baut, was Sie beschreiben. Sie entscheidet aber nicht für Sie, welche Daten wer sehen darf, ob eine Warnung ernst ist und wann ein Update fällig wird. Das ist Betrieb, und der beginnt mit dem ersten Nutzer, der sich anmeldet.
Was gehört zum sicheren Betrieb einer KI-gebauten App?
Ob die App mit Lovable, einem anderen KI-Werkzeug oder klassisch entwickelt wurde, macht dabei kaum einen Unterschied. Diese Punkte gehören dazu:
- Wissen, welche Daten die App speichert. Gibt es Anmeldungen, Formulare, Uploads? Personenbezogene Daten machen aus einem Bastelprojekt ein System, für das Sie haften.
- Zugriffsregeln prüfen, nicht voraussetzen. Bei Supabase heißt das: Ist RLS für jede Tabelle aktiv, und gibt es für jede Tabelle passende Regeln? Ein einfacher Test ist, die Seite ohne Anmeldung aufzurufen und zu prüfen, welche Daten der öffentliche Schlüssel liefert. Geheime Schlüssel mit vollen Rechten gehören nie in den Code der Webseite.
- Warnungen der Plattform lesen und abarbeiten. Sowohl Lovable als auch Supabase sagen, dass sie Nutzer über Lücken informieren. Das hilft nur, wenn jemand die Hinweise liest und umsetzt, bevor die App online geht.
- Updates und Patches einplanen. Jede App nutzt Bibliotheken und Dienste, in denen Lücken gefunden werden. Wie schnell das gehen kann, hat die PHP-Lücke php2shell im Oktober gezeigt; das Handelsblatt verweist ebenfalls darauf. Updates müssen regelmäßig eingespielt werden, nicht erst, wenn etwas passiert ist.
- Nach Änderungen erneut prüfen. Jeder neue Textbefehl an die KI kann Tabellen, Regeln oder Schlüssel ändern. Was gestern sicher war, muss es nach der nächsten Änderung nicht mehr sein.
- Bei sensiblen Daten professionell prüfen lassen. Das empfiehlt auch Jansen im Handelsblatt: Sobald sensible Daten im Spiel sind, bleibe eine professionelle Überprüfung unverzichtbar.
Wie ich das bei meinen eigenen Projekten handhabe
Vibe Coding ist ein guter Weg, eine Idee schnell auszuprobieren. Für Anwendungen, mit denen ein Unternehmen arbeitet, gehört der Betrieb aber von Anfang an dazu. So gehe ich vor, wenn ich für Kunden Prozessautomatisierungen, kleine Anwendungen oder Dashboards entwickle:
- Sicher implementieren: Zugriffsrechte, Schlüssel und Anmeldung sind Teil der Entwicklung, nicht ein Schritt, der später nachgeholt wird.
- Patch-Management: Sicherheitsmeldungen im Blick behalten und Updates zeitnah einspielen, nicht erst, wenn etwas passiert.
- Monitoring: Die Anwendungen werden überwacht, damit Ausfälle und Auffälligkeiten auffallen, bevor Nutzer sie melden.
Häufige Fragen
Was ist Vibe Coding? Software entsteht, indem man einer KI in natürlicher Sprache beschreibt, was sie bauen soll, statt selbst zu programmieren. Plattformen wie Lovable versprechen, dass dafür keine Programmierkenntnisse nötig sind.
War der Datenabruf bei Lovable ein Hackerangriff? Nein. Laut dem vom Handelsblatt befragten Experten Dirk Koch wurde ein öffentlicher Schlüssel genutzt, den die Seiten selbst jedem bereitstellen. Das Problem waren fehlende Zugriffsregeln in der Datenbank.
Was ist Row Level Security (RLS)? Ein Sicherheitsmechanismus der Datenbank, der regelt, wer welche Zeilen einer Tabelle lesen oder ändern darf. Fehlt er, kann der öffentliche Schlüssel einer Webseite unter Umständen alle Daten einer Tabelle liefern.
Ist meine Lovable- oder Supabase-App betroffen? Das lässt sich nur am konkreten Projekt prüfen. Ein erster Schritt: in Supabase für jede Tabelle kontrollieren, ob RLS aktiv ist und passende Regeln existieren, und die Hinweise von Lovable und Supabase ernst nehmen.
Reicht es, wenn der Anbieter sichere Standards einführt? Sie helfen, ersetzen aber nicht den eigenen Blick. Bestehende Projekte, eigene Änderungen und Updates bleiben in der Verantwortung des Betreibers.
Quelle
- Handelsblatt, „Lovable: Experten finden Datenlücke bei beliebter KI-Coding-Plattform“, Lina Knees, 02.11.2026: https://www.handelsblatt.com/technik/ki/lovable-experten-finden-datenluecke-bei-beliebter-ki-coding-plattform/100264923.html
