Lovable: Studie findet personenbezogene Daten auf Tausenden von Anwendungen ohne Login zugänglich
Das Hamburger Sicherheitsunternehmen Crissy Field hat 159 041 mit Lovable erstellte Projekte analysiert. Von 24 664 Websites, die bereits beim Laden Daten aus Supabase abriefen, ließen 7 403 das Auslesen von Tabellen mit E-Mail-Adressen, teils Passnummern oder Zahlungsdaten zu.
Das Versprechen des „Vibe Coding“ stößt auf eine sehr konkrete Frage: Wer schützt die Daten? Das Hamburger Sicherheitsunternehmen Crissy Field hat 159 041 Projekte untersucht, die mit Lovable erstellt wurden, jener schwedischen Plattform, die Prompts in natürlicher Sprache in Webanwendungen verwandelt. Das Ergebnis: Auf Tausenden von Websites waren persönliche Informationen, teils hochsensibel, völlig ohne Login lesbar. Die Recherche, die gemeinsam mit dem Handelsblatt (Artikel vom 2. November 2026) durchgeführt wurde, wird in einem Bericht von Crissy Field mit aktualisierten Zahlen detailliert dargelegt.
Was die Studie gemessen hat
Crissy Field konzentrierte sich auf Supabase, jenen Datenbankdienst, den das Unternehmen als den am häufigsten von Lovable-Projekten genutzten einstuft. Lovables eigene Datenbanken, die Ende 2025 eingeführt wurden, wurden nicht untersucht.
| Schritt | Anzahl |
|---|---|
| In Common Crawl identifizierte Lovable-Projekte (Dez. 2025 bis Sept. 2026) | 159 041 |
| Projekte, die Supabase nutzen | 34 545 |
| Websites, die bereits beim Laden ohne Login Supabase-Datensätze übertragen | 24 664 |
| Websites, auf denen Tabellen mit E-Mail-Adressen lesbar waren | 7 403 (30 Prozent), in 10 560 Tabellen |
Die erste Kennzahl stellt an sich noch keine Schwachstelle dar: Eine Anwendung kann bestimmte Daten durchaus öffentlich anzeigen. Das Problem zeigt sich im nächsten Schritt. Mit einfachen Nur-Lese-Abfragen und demselben API-Schlüssel, den die Website verwendet, konnten die Forscher weitere Tabellen auslesen. Crissy Field veröffentlicht seine Zugriffsmethode nicht, um keine neuen Angriffe zu begünstigen, und lud lediglich Stichproben aus den Datenbanken herunter.
Von Pässen bis zu privaten Nachrichten
Die im Bericht genannten Beispiele wiegen schwer:
- Ein deutsches Forum legte über 80 000 Profile (Name, E-Mail-Adresse, Geburtsdatum) und über 200 000 Chatnachrichten offen;
- Veranstalter und Gastronomiebetriebe ließen Zehntausende Verkaufsdatensätze mit Telefonnummern, Postanschriften, Zahlungsinformationen und Ticketcodes einsehen;
- Eine Immobilienverwaltung exponierte KI-generierte Zusammenfassungen interner E-Mails über Mieter und Geschäftspartner;
- Ein Dienstleister stellte über 1 000 Datensätze mit Reisepassnummern, Ablaufdaten und Nationalitäten ungeschützt ins Netz;
- Andernorts: Verträge, Rechnungen, Fotoalben, interne WhatsApp-Verläufe und 280 000 E-Mails, die an Kunden eines Anbieters verschickt worden waren.
Crissy Field erklärt, nicht wissen zu können, ob diese Daten missbräuchlich verwendet wurden, erinnert jedoch daran, dass sie für Phishing, Ticketbetrug oder Identitätsdiebstahl genutzt werden können.
Die Grenzen der 30-Prozent-Marke
Der Bericht äußert sich vorsichtig über seine eigene Statistik. Eine E-Mail-Adresse kann ein öffentlicher Kontakt oder ein Testdatum sein; umgekehrt entgehen Datensätze ohne E-Mail-Adresse dieser Zählung. Die 30 Prozent beziehen sich lediglich auf die 24 664 näher untersuchten Websites, und die aus Common Crawl gewonnene Stichprobe ist nicht repräsentativ für die Gesamtheit aller Lovable-Anwendungen. Es handelt sich folglich um keine bestätigte Datenleak-Rate.
Wer trägt die Verantwortung?
Crissy Field verweist auf eine Diskrepanz: Lovable wirbt damit, dass keinerlei technische Vorkenntnisse nötig seien, während die eigenen Nutzungsbedingungen die Verantwortung für Anwendungen und Datenverarbeitung vollständig auf die Kunden abwälzen. Laut India Today unter Berufung auf das Handelsblatt entgegnete Lovable, das Problem sei nicht spezifisch für die eigene Plattform, sondern branchenweit verbreitet. Eine öffentliche Erklärung des Anbieters konnten wir zum jetzigen Zeitpunkt nicht ausfindig machen.
Die Sicherheitsforscher räumen ein, dass Rechteprobleme auch bei manuell programmierten Anwendungen vorkommen. Doch bei Lovable folgen die Datenbankintegrationen wiederkehrenden Mustern: Ein Ansatz, der bei einer Anwendung funktioniert, lässt sich bei vielen weiteren wiederholen. Nutzern ohne technischen Hintergrund fällt es zudem schwerer, solche Fehler zu erkennen. Ihre Empfehlung: Zugriffsrechte, Schnittstellen und die Trennung zwischen Konten vor dem Umgang mit echten Kundendaten überprüfen zu lassen – und dies nach jeder größeren Änderung zu wiederholen.
Unsere Einschätzung
Das Problem ist nicht KI-spezifisch: Eine falsch konfigurierte Datenbank bleibt eine falsch konfigurierte Datenbank, unabhängig davon, ob sie von einem Menschen oder einem Software-Agenten angebunden wurde. Doch Werkzeuge zur automatischen App-Generierung vervielfachen die Anzahl der Projekte, die von Personen ins Netz gestellt werden, denen nicht bewusst ist, dass eine Datenbank ohne sauber definierte Zugriffsregeln weit über das hinaus ausgelesen werden kann, was die eigentliche Anwendung anzeigt. Die Studie belegt weder ein massives Datenleck noch einen tatsächlichen Missbrauch, und ihre Stichprobe ist nicht repräsentativ; sie zeigt jedoch, dass „No-Code“ keinesfalls „No-Security“ bedeutet. Für diese Plattformen besteht die Herausforderung nun darin, Systeme standardmäßig sicher zu konfigurieren und das Onlinestellen zu blockieren, solange sensible Daten ungeschützt offenliegen – anstatt die Verantwortung schlicht an die Kunden weiterzureichen. Wer eine solche Anwendung veröffentlicht hat, sollte sie im ausgeloggten Zustand testen und die Zugriffsregeln prüfen lassen, bevor darin echte Daten gespeichert werden.
Quellen
- Crissy Field — Lovable: Many Apps Built on the Platform Expose Sensitive Data (Forschungsbericht) Primärquelle
- India Today — AI app-maker Lovable apps expose personal details, researchers find thousands of cases (3. November 2026) Sekundärquelle
Eine Primärquelle stammt direkt von dem betreffenden Unternehmen, Labor oder der Organisation. Eine Sekundärquelle gibt die Information wieder, ohne ihr Urheber zu sein: Wir kennzeichnen sie als solche. Einen Fehler entdeckt? Lesen Sie unsere Korrekturrichtlinie.
