KI-Radar · 13. Oktober 2026

Datenleck ohne Angriff: Was in deiner App offen liegt

Am 25. September hat die Sicherheitsfirma UpGuard eine Untersuchung veröffentlicht: 16.326 Datenbanken auf der Plattform Supabase gaben ihre Tabellen für jeden preis, der Adresse und Schlüssel aus dem Quelltext der zugehörigen Website ausliest. Darin standen Namen, Adressen und Telefonnummern, in einem Teil der Fälle Passwörter und Zugangstoken. TechCrunch hat am selben Tag darüber berichtet und einzelne Fälle benannt: die Kennzeichenliste eines Parkservice, Daten eines Einwanderungs- und Relocation-Dienstes, die Datenbank eines Konsulats.

Kein Angriff, kein Einbruch, keine Lösegeldforderung. Eine fehlende Voreinstellung. Das ist die unspektakulärste Art, Kundendaten zu verlieren — und deshalb die wahrscheinlichere.

Warum ein Datenleck ohne Angriff das wahrscheinlichere ist

In Ausgabe 2 ging es um Angreifer, die KI benutzen. Hier läuft es umgekehrt: Es braucht keinen Angreifer. Es reicht, dass eine Schutzfunktion aus ist und die Adresse im Quelltext der eigenen Website steht.

UpGuard benennt die Ursache genau: „Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default.“ Ohne Fachwort: Über den Tabelleneditor im Dashboard angelegt, hat eine Tabelle den Zeilenschutz aktiv — im Englischen Row Level Security, kurz RLS. Per SQL oder über die Programmierschnittstelle angelegt, hat sie ihn nicht. Es kommt auf den Anlegeweg an, nicht auf Mensch oder Maschine. Und genau über die Schnittstelle arbeiten die Baukästen, mit denen heute Anwendungen in einem Wochenende entstehen.

Dazu kommt der zweite Fehler, den UpGuard beschreibt: Der Schlüssel, mit dem die Seite auf die Datenbank zugreift, ist für die Öffentlichkeit gedacht und wird behandelt, als wäre er geheim. Er steht im Quelltext, wo ihn jeder lesen kann, der hinsieht.

Dass das kein Problem kleiner Baustellen ist, zeigte dieselbe Woche von der anderen Seite: Am 25. September berichtete TechCrunch, dass Agenten aus OpenAIs Forschungsumgebung 53 Nutzerbilder auf öffentliche Bildhoster gestellt hatten, ohne Wissen des Unternehmens — offengelegt hat das OpenAI selbst, bei der eigenen Aufarbeitung. Wer Arbeit an Agenten übergibt, verliert leicht den Überblick, was sie veröffentlichen.

Die Zahlen, und was sie nicht hergeben

UpGuard hat aus Builtwith- und Chrome-UX-Report-Daten rund 300.000 Domains zusammengetragen, deren JavaScript-Dateien auf Supabase hindeuten, und diese abgefragt — auf eine Tabelle namens „users“, weil das ein häufiger Tabellenname ist. Ergebnis: 16.326 Datenbanken mit lesbaren Tabellen. In mehr als der Hälfte fanden sich Hinweise auf personenbezogene Daten, in einem kleineren Teil Passwörter oder Zugangstoken, in sehr wenigen Fällen etwas, das nach Kreditkartendaten aussieht.

Was die Untersuchung nicht abdeckt, schreibt UpGuard selbst dazu: Bewertet wurden die Tabellenstrukturen, nicht jede einzelne Zeile, und nachgeprüft wurde nur eine Handvoll Fälle. Dazu kommt eine Verzerrung, die UpGuard selbst benennt: Der hohe Anteil personenbezogener Daten kommt zum Teil daraus, dass nach einer Tabelle namens „users“ gesucht wurde — also dort, wo Personendaten zu erwarten sind. Und die Zahl sagt, wie viele Datenbanken offen standen, nicht wie viele ausgelesen wurden. Sie deckt außerdem nur Supabase ab und nur Domains, die in diesen beiden Datenquellen vorkommen — andere Baukästen und andere Datenbankdienste sind nicht mitgezählt. Einen Österreich-Anteil nennt sie nicht.

Zum Maßstab, wie viel inzwischen so gebaut wird: Lovable, einer dieser Baukästen, nannte am 24. September einen annualisierten Umsatz von 600 Millionen Dollar — Mitgründer Fabian Hedin auf dem HumanX-Summit in Amsterdam. Das ist eine Firmenangabe von einer Bühne, keine geprüfte Bilanz, und sie misst Umsatz, nicht Sicherheit. Über die Menge sagt sie trotzdem etwas.

Was das für einen Betrieb in Österreich heißt

Das betrifft dich auch, wenn du von Supabase nie gehört hast.

Wenn bei dir irgendwo eine kleine Anwendung läuft — ein Anmeldeformular für Kurse, eine Terminliste, ein Kundenportal, ein Bestellformular, das jemand „schnell gemacht“ hat —, dann ist die entscheidende Frage nicht, wer sie gebaut hat. Sie lautet, wer nach der DSGVO dafür geradesteht. Das bist du, nicht der Baukasten und nicht die Agentur.

Und die Uhr ist kurz. Die österreichische Datenschutzbehörde schreibt, eine Verletzung sei „unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde“ zu melden. Bei hohem Risiko kommt nach Artikel 34 DSGVO die Benachrichtigung der betroffenen Personen dazu — also deiner Kundschaft.

Die heimische Zahl daneben: Im Tätigkeitsbericht 2025, veröffentlicht im März 2026, weist die Datenschutzbehörde 1.704 Meldungen nach Artikel 33 DSGVO für das Jahr 2025 aus. Für 2024 waren es 1.216, für 2023 1.028 — ein Plus von 40 Prozent im letzten Jahresschritt. Was diese Zahl nicht abdeckt: Sie zählt gemeldete Verletzungen, nicht eingetretene. Ein offener Datenbestand, den niemand bemerkt, steht in keiner Statistik. Und sie sagt nicht, wie viele dieser Meldungen auf Fehlkonfigurationen zurückgehen und wie viele auf Angriffe.

Das ist keine Rechtsauskunft — bei konkretem Bedarf zur Anwältin.

Was jetzt zu tun ist

Fünf Punkte, jeder heute umsetzbar, jeder ohne uns:

  1. Schreib auf, wo bei dir Kundendaten liegen. Nicht die Technik, die Orte: Website-Formular, Newsletter, Terminbuchung, die Liste am Empfang, die Anwendung, die jemand nebenbei gebaut hat. Diese Aufstellung gibt es in den meisten Betrieben nicht, und ohne sie bleibt jede weitere Frage unbeantwortbar.
  2. Frag bei jedem selbstgebauten Werkzeug zwei Sätze nach. „Ist der Zeilenschutz auf allen Tabellen aktiv — und greifen die Regeln dahinter auch?“ Der Schalter allein schützt nichts — das schreibt UpGuard dazu. Wer es gebaut hat, beantwortet beides in zehn Minuten. Kommt keine klare Antwort, ist das die Antwort.
  3. Mach den Selbsttest, der nichts kostet — auf deiner eigenen Seite. Ruf sie im Browser auf, drück F12 (am Mac Cmd+Option+I) und schau im Netzwerk-Reiter, was zurückkommt. Stehen dort mehr Daten, als am Bildschirm zu sehen sind, liegt mehr offen als gedacht. Ein Freibrief ist das nicht: Eine offene Tabelle, die deine Anwendung nie abfragt, erscheint dort nicht.
  4. Leg vor dem nächsten Werkzeug fest, welche Daten hineindürfen. Ein Terminwunsch mit Vorname und Telefonnummer ist etwas anderes als eine Gesundheitsangabe oder eine Kontonummer. Diese Entscheidung ist billiger als die Meldung danach.
  5. Notier jetzt, wen du in diesen 72 Stunden anrufst. Datenschutzbehörde, die Person, die die Anwendung betreut, im Zweifel die Anwältin. Drei Nummern an einem Ort ersparen dir den schlechtesten Tag.

Was wir nicht wissen

Die Offenlegung zuerst: Wir arbeiten selbst mit Supabase. Das steht auf unserer Seite zu Softwareentwicklung. Das ist kein Grund, das Werkzeug schlechtzureden, und keiner, die Untersuchung wegzuwischen. Es ist der Grund, warum wir die Voreinstellung kennen, um die es hier geht.

Die Gegenrede gehört dazu, und sie ist nicht schwach: Bil Harmer, bei Supabase für Informationssicherheit zuständig, verweist gegenüber TechCrunch darauf, dass das Unternehmen sichere Voreinstellungen und Werkzeuge bereitstelle und die Kundschaft ihre Projekte selbst konfiguriere. Für den Tabelleneditor stimmt das, wie die Dokumentation zeigt — diese Einordnung ist unsere, nicht seine. Ob eine Plattform den Weg über die Schnittstelle anders absichern müsste, wenn ihn inzwischen überwiegend Maschinen benutzen, ist eine offene Frage, und keine, die wir entscheiden.

Wir wissen nicht, wie viele der 16.326 Datenbanken zu Betrieben gehören und wie viele zu Bastelprojekten ohne echte Daten. Wir wissen nicht, ob und wie oft die offenen Bestände tatsächlich ausgelesen wurden. Und wir wissen nicht, wie es bei vergleichbaren Diensten aussieht — gesucht wurde bei einem.

Die Zahl, die es für Österreich nicht gibt: Niemand erhebt, wie viele Anwendungen in heimischen Betrieben mit KI-Werkzeugen entstanden sind. Wer dir dazu einen Prozentsatz nennt, hat ihn geschätzt.

Fragen zu einem dieser Punkte? Schreib uns an office@combastic.com.

Quellen