---
title: "Lovable-Datenleck: Zugriffsrechte nach dem Fix prüfen"
canonical: https://wavect.io/de/blog/lovable-supabase-data-exposure/
language: de
description: "Lovable-Datenleck einordnen: Prüfe korrigierte Supabase-Rechte mit einem reproduzierbaren Test, Nutzer A/B und Zugriffen ohne Anmeldung. Sichere die Nachweise."
image: "https://wavect.io/img/blog/headers/header_lovable-supabase-data-exposure.png"
author: ["Kevin Riedl"]
published: "2026-11-04"
updated: "2026-11-04"
reviewed: "2026-11-04"
---

# Lovable-Datenleck: So prüfst du korrigierte Zugriffsrechte

[**Zurück**](/de/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/)

[Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt

15 Min. Lesezeit · 4. November 2026 Zuletzt geprüft 4. November 2026

[**Weiter**](/de/blog/lovable-bolt-replit-app-due-diligence/)

TL;DR

Prüfe eine Korrektur der Datenzugriffsrechte deiner Lovable-App mit erlaubten und verbotenen Anfragen. Lege fest, wer welche Datensätze und Felder lesen und welche Werte ändern darf. Führe den synthetischen Policy-Regressionstest aus und wiederhole die passenden Fälle an der bereitgestellten Anwendung mit echten Nutzeridentitäten. Ein lokales Ergebnis oder ein Scan ohne Befund belegt nur den jeweils geprüften Umfang. Bewahre die Änderung, positive Kontrollen, abgewiesene Operationen und offene Prüfungen zusammen auf, bevor du den Befund schließt.

Du hast nach einer Sicherheitswarnung eine Datenbank-Policy geändert. Dein eigenes Konto funktioniert weiterhin. Bevor du den Befund schließt, prüfe, ob ein anderer Kunde deine privaten Datensätze lesen kann und ob eine Anfrage ohne Anmeldung Daten erhält, die ihr nicht zustehen.

**Um korrigierte Zugriffsrechte deiner Lovable-App zu prüfen, legst du die beabsichtigten Berechtigungen fest und testest erlaubte sowie verbotene Operationen mit synthetischen Datensätzen. Anschließend wiederholst du diese Tests über die bereitgestellten Datenzugriffe mit echten Anwendungsidentitäten.** Bewahre die Ergebnisse vor und nach der Änderung auf. Ein bestandener lokaler Policy-Test belegt das Verhalten einer bestimmten Regel; der Zugriff in Produktion braucht eine eigene Nachprüfung.

**Recherchestand: 4. November 2026.** Die folgenden Zahlen zum Vorfall stammen von den genannten Forschern. Unser separates Beispiel verwendet synthetische Daten und lokale PostgreSQL-Policies. Die Prüfungen an der gehosteten Anwendung sind ein vorgeschlagenes Vorgehen für eine Umgebung, die dir gehört oder die du prüfen darfst.

**Unabhängigkeit und Marken:** Wavect veröffentlicht diese Seite und ist selbst Anbieter, wir haben also ein wirtschaftliches Interesse daran. Mit den hier genannten anderen Unternehmen sind wir weder verbunden noch von ihnen beauftragt oder empfohlen, und alle Firmennamen, Marken und Warenzeichen Dritter gehören ihren jeweiligen Inhabern. Aussagen über andere Anbieter stammen aus öffentlich zugänglichen Quellen, vor allem aus deren eigenen veröffentlichten Seiten, mit Stand des auf dieser Seite genannten Prüfdatums, und können sich seither geändert haben. Bitte prüfe sie vor einer Entscheidung selbst. Diese Seite wurde nach bestem Wissen und Gewissen erstellt, mit dem Ziel, möglichst objektiv zu bleiben. Wenn dir etwas falsch oder unfair erscheint, schreib uns und wir korrigieren es: [office@wavect.io](mailto:office@wavect.io)

## Was zeigt der Bericht zum Lovable-Datenleck?

Der [Novemberbericht von Crissy Field](https://www.crissyfield.de/research/lovable-en/) beschreibt Datenabrufe ohne Anmeldung in ausgewählten, mit Lovable erstellten Anwendungen. Die Forscher identifizierten Projekte in Common-Crawl-Archivdaten von Dezember 2025 bis September 2026. Die Zahlen aktualisieren den Handelsblatt-Beitrag vom 2. November und beziehen sich auf unterschiedliche Teilmengen.

| Auswertungsschritt | Anzahl |
| --- | --- |
| Identifizierte Projekte | 159.041 |
| Davon mit Supabase | 34.545 |
| Datensätze schon beim Laden der Seite abrufbar | 24.664 |
| Websites mit E-Mail-Adressen in zusätzlichen Datenabrufen | 7.403, verteilt auf 10.560 Tabellen |

Die genannten 30 % entsprechen 7.403 von 24.664 Websites und sind **keine bestätigte Datenleckquote**. E-Mail-Treffer können öffentliche Kontakte oder Testdaten sein; die Stichprobe ist nicht repräsentativ. Lovables eigenes Datenbankangebot war ausgeschlossen.

Die Beispiele umfassen über 200.000 Nachrichten eines deutschen Lifestyle-Forums, mehr als 1.000 Datensätze mit Identitätsangaben einschließlich Passnummern bei einem Dienstleister sowie Zahlungsinformationen in Verkaufsdatensätzen. Der Bericht nennt keine konkreten Zahlungskartenfelder und weist keinen Missbrauch nach. Daraus lässt sich weder die Betroffenheit deiner Anwendung noch ihr aktueller Reparaturstand ableiten.

## Ist das derselbe Vorfall wie Lovables offengelegte Chatverläufe?

Der Vorfall mit Lovables Chatverläufen im April betraf den Zugriff auf das Projekt im Entwicklungswerkzeug. Die Datenbank der bereitgestellten Anwendung ist eine andere Zugriffsebene. In der [Stellungnahme vom 22. April](https://lovable.dev/blog/our-response-to-the-april-2026-incident) beschreibt Lovable eine Regression vom 3. Februar bis zum 20. April: Angemeldete Lovable-Nutzer konnten mit dem Link zu einem öffentlichen Projekt dessen Quellcode und Chatverlauf abrufen.

Lovable erklärt, die Regression behoben zu haben; private Projekte und Lovable Cloud seien davon nicht betroffen gewesen. Diese Aussage überprüft nicht die Berechtigungen deiner bereitgestellten Anwendung.

| Ebene | Zu klärende Frage | Geeigneter Nachweis |
| --- | --- | --- |
| Projekt im Editor | Wer kann Quellcode, Unterhaltungen mit dem Builder und unveröffentlichte Arbeit öffnen? | Projektmitgliedschaften und Sichtbarkeitseinstellungen |
| Veröffentlichte Website | Wer erreicht die bereitgestellten Seiten? | Zugriffseinstellungen und ein Seitenaufruf mit der vorgesehenen Identität |
| Anwendungsdaten | Welche Datensätze und Operationen erreicht der Aufrufer? | Tatsächliche Backend-Antworten und der daraus entstandene Datenbankzustand |

Unser [Leitfaden zur Due Diligence von Lovable-Anwendungen](/de/blog/lovable-bolt-replit-app-due-diligence/) behandelt die weitergehende Prüfung von Eigentum und Einsatzreife. Diese Nachprüfung beantwortet die engere Frage, ob ein konkreter Befund zum Datenzugriff geschlossen werden kann.

## Warum können Daten trotz Login-Seite abrufbar sein?

Eine Login-Seite steuert die Benutzeroberfläche. Welche Daten eine Anfrage erreichen darf, muss das Backend durchsetzen. Bei einer Supabase-App mit direkter Browseranbindung beweisen weder eine versteckte Seite noch eine in JavaScript gefilterte Liste, dass die Datenbank den Zugriff korrekt beschränkt. Prüfe die Datenanfrage selbst, auch ohne angemeldeten Nutzer.

Die [Dokumentation zu Supabase-API-Schlüsseln](https://supabase.com/docs/guides/getting-started/api-keys) unterscheidet den Publishable Key von der Identität eines Nutzers. Ein Publishable Key gehört in öffentliche Clients. Ohne Nutzersitzung verwenden Anfragen `anon`, mit einer angemeldeten Sitzung `authenticated`. Secret Keys und ältere `service_role`-Zugangsdaten brauchen eine gesonderte Behandlung, weil ihr erhöhter Zugriff RLS umgeht.

**Row-Level Security ist der PostgreSQL-Mechanismus, der festlegt, auf welche Zeilen eine Operation zugreifen darf.** Der [RLS-Leitfaden von Supabase](https://supabase.com/docs/guides/database/postgres/row-level-security) trennt Tabellenrechte von Zeilen-Policies: Grants erlauben eine Operation auf der Tabelle; Policies begrenzen die betroffenen Zeilen. Prüfe beides. Ein entfernter Button im Frontend ändert keine dieser Berechtigungen.

Eine Listenabfrage mit der ID des aktuellen Nutzers kann beispielsweise genau die richtigen Zeilen anzeigen, während eine umfassendere erlaubte Abfrage weitere Datensätze liefert. Für die Nachprüfung ändern wir den angeforderten Datensatz und lassen den Aufrufer unverändert. Das Backend muss die Besitzerregel auch dann durchsetzen, wenn die Oberfläche eine solche Anfrage nie anbieten würde.

## Was muss ein Berechtigungstest nachweisen?

Ein Berechtigungstest muss zeigen, dass erlaubte Arbeit gelingt und unzulässige Zugriffe unter einer bekannten Identität scheitern. Beginne mit zwei synthetischen Nutzern und getrennten privaten Datensätzen. Lege zuerst die erlaubten Felder und Operationen fest. Ein Test kann eine Policy korrekt bestätigen, obwohl diese dem beabsichtigten Produktverhalten widerspricht.

| Aufrufer | Lesen | Erlaubte Änderung | Muss abgewiesen werden |
| --- | --- | --- | --- |
| Besucher ohne Anmeldung | Keine privaten Zeilen | Keine auf dieser privaten Tabelle | Private Datensätze lesen, anlegen oder ändern |
| Nutzer A | Die für A erlaubten Felder | Die für A freigegebenen bearbeitbaren Felder | Eine Zeile von B lesen, für B schreiben oder den Besitzer ändern |
| Nutzer B | Die für B erlaubten Felder | Die für B freigegebenen bearbeitbaren Felder | Die entsprechenden Operationen an Datensätzen von A |
| Backend-Aufgabe | Nur innerhalb ihres dokumentierten Auftrags | Nur innerhalb ihres dokumentierten Auftrags | Beliebige Datensatzanfragen eines ungeprüften Aufrufers ausführen |

Nimm beabsichtigt öffentliche Inhalte als eigenen positiven Testfall auf. Ein öffentlicher Katalog soll weiterhin lesbar sein, wenn das seine Aufgabe ist. Bei privaten Daten muss der Besitzer den vorbereiteten Datensatz unmittelbar vor dem Test des fremden Zugriffs lesen können. Eine leere Tabelle oder eine defekte Umgebung kann sonst jede Prüfung auf verweigerten Zugriff erfolgreich aussehen lassen.

Unterscheide außerdem Gastkonten ausdrücklich. [Anonyme Anmeldungen bei Supabase Auth](https://supabase.com/docs/guides/auth/auth-anonymous) erzeugen Auth-Nutzer mit der Rolle `authenticated` und dem JWT-Claim `is_anonymous`. Wenn du ausschließlich dauerhafte Konten zulassen willst, reicht diese Rolle dafür nicht aus. Ergänze die passende Policy-Bedingung und die entsprechende Testidentität.

Bei Teams und Organisationen ersetzt du die einfache Besitzerregel durch die tatsächlichen Mitgliedschafts- und Rollenregeln. Prüfe auch einen Nutzer, dessen Mitgliedschaft entfernt wurde. Entscheide, welche Hintergrundaufgaben danach weiterhin berechtigt sind, und teste genau diese Vorgabe. Nicht jeder Zugriff muss auf dieselbe Weise enden.

## Was ergab unser synthetischer PostgreSQL-Test?

Unser synthetischer PostgreSQL-Test reproduzierte offene Lesezugriffe, zwei unvollständige Korrekturen und eine auf Besitzer und Mandant begrenzte Policy. **Alle 23 protokollierten Prüfungen bestanden mit dem jeweils erwarteten Ergebnis.** Dazu gehörte der Nachweis der absichtlich unsicheren Zustände. Im korrigierten Zustand funktionierten die erlaubten Operationen, während die getesteten Zugriffe auf fremde Nutzer und Mandanten abgewiesen wurden.

Wir verwendeten Node.js 24.22.1 und `@electric-sql/pglite` 0.5.15; die Laufzeit meldete PostgreSQL 18.6. [PGlite stellt eine PostgreSQL-Laufzeit im Arbeitsspeicher bereit](https://pglite.dev/docs/). Das Testprojekt legt drei Notizen an: Alice und Bob teilen sich Mandant A, Carol gehört zu Mandant B. Jeder Nutzer besitzt eine Notiz.

| Policy-Zustand | Zeilen ohne Anmeldung | Zeilen für Alice | Einordnung |
| --- | --- | --- | --- |
| RLS deaktiviert, Leserechte vorhanden | 3 | 3 | Die Grenze zum Schutz privater Datensätze greift nicht. |
| RLS aktiviert, keine Policies | 0 | 0 | Der Zugriff wird verweigert, aber auch der berechtigte Besitzer kann nicht lesen. |
| Lese-Policy für angemeldete Nutzer mit `USING (true)` | 0 | 3 | Gesperrte Zugriffe ohne Anmeldung schützen noch nicht vor anderen Nutzern. |
| Bedingungen für Besitzer und Mandant | 0 | 1, genau `alice-note` | Alice kann ihre Notiz lesen, ohne Bobs oder Carols Notiz zu erhalten. |

Der Testtreiber prüft vor jeder Operation die tatsächlich wirksame PostgreSQL-Rolle sowie Nutzer- und Mandanten-ID. Bob und Carol lesen jeweils genau ihre eigene vorbereitete Notiz. Alices Identität mit einer falschen Mandanten-ID liest null Zeilen. Diese positiven Kontrollen unterscheiden eine funktionierende Beschränkung von einer leeren oder unerreichbaren Datenbank.

Dies ist der unveränderte Policy-Ausschnitt aus dem Testprojekt. **Die Hilfsfunktionen `fixture.uid()` und `fixture.tenant_id()` lesen SQL-Einstellungen, die der Test vorgibt.** Diese Funktionen ersetzen die Identität lokal und sind weder Supabase-Auth-Funktionen noch eine JWT-Prüfung. Der Ausschnitt ist keine Migration für Produktion; eine vertrauenswürdige Prüfung der Mandantenzugehörigkeit wurde damit nicht getestet.

```
DROP POLICY signed_in_read ON public.notes;
CREATE POLICY private_notes ON public.notes FOR ALL TO authenticated
  USING (owner_id = fixture.uid() AND tenant_id = fixture.tenant_id())
  WITH CHECK (owner_id = fixture.uid() AND tenant_id = fixture.tenant_id());
```

Alices erlaubte Update-, Insert- und Delete-Operationen lieferten jeweils einen erwarteten Datensatz zurück. Ein Update von Bobs oder Carols Notiz sowie das Löschen von Bobs Notiz lieferten null Zeilen. Versuche, den Besitzer oder Mandanten zu ändern oder eine Notiz für Bob anzulegen, lösten SQLSTATE `42501` aus. Nach jeder abgewiesenen Schreiboperation verglich der Testtreiber einen Snapshot der gesamten Tabelle und bestätigte, dass sie unverändert war.

Eine separate Rolle mit `BYPASSRLS` las trotz Alices Testidentität alle drei Datensätze. Außerdem deaktivierten wir RLS gezielt erneut: Die Prüfung des Besitzerzugriffs erkannte die zusätzlichen Zeilen. Nach erneuter Aktivierung kam wieder genau eine Zeile zurück. Der Regressionstest reagiert damit auf eine tatsächliche Policy-Änderung.

[Policy-Regressionstest und protokollierte Ergebnisse herunterladen](/downloads/lovable-supabase-data-exposure-fixture.zip). Entpacke das Archiv und führe anschließend aus:

```
npm ci --ignore-scripts
npm test
```

Das Paket enthält die Lockdatei für die Abhängigkeiten und `results.json`. Es prüft PostgreSQL-Grants und -Policies mit kontrollierten lokalen Identitäten. Supabase Auth, JWT-Prüfung, PostgREST, gehostete HTTP-Antworten, Views, Storage und Edge Functions werden nicht getestet. Die folgenden Prüfungen an der bereitgestellten Anwendung bleiben für deren tatsächlichen Umfang erforderlich.

## Warum kann eine Korrektur trotz aktiviertem RLS scheitern?

Auch eine Tabelle mit aktiviertem RLS kann Zugriffe erlauben, die der beabsichtigten Regel widersprechen. Prüfe alle anwendbaren Policies und Privilegien, anschließend alternative Datenzugriffe und die zurückgegebenen Felder. Erlaubte Operationen müssen weiterhin funktionieren; zugleich musst du begrenzen, welche neuen Werte eine Schreiboperation speichern darf.

Die [PostgreSQL-Referenz zu Zeilen-Policies](https://www.postgresql.org/docs/18/ddl-rowsecurity.html) erklärt, dass permissive Policies mit `OR` verknüpft werden. Eine neue, enge Besitzer-Policy beschränkt das Ergebnis nicht, solange eine anwendbare Allow-all-Policy bestehen bleibt. Die Referenz erklärt auch, warum Superuser, Rollen mit `BYPASSRLS` und normalerweise Tabellenbesitzer ungeeignet sind, um gewöhnliche Aufrufer im Test zu vertreten.

Für Zeilen und Felder brauchst du getrennte Entscheidungen. Laut [Supabase-Leitfaden zu Spaltenrechten](https://supabase.com/docs/guides/database/postgres/column-level-security) legt RLS nicht fest, welche Spalten innerhalb einer erlaubten Zeile zugänglich sind. Wir würden öffentliche Profilfelder von internen Datensätzen trennen oder bewusst entworfene Spaltenrechte einsetzen. Prüfe, ob Tabellenrechte weiterhin den Zugriff auf Spalten erlauben, die du sperren willst.

Beim Aufruf einer Funktion können sich die wirksamen Privilegien ändern. Supabase dokumentiert, dass eine [Datenbankfunktion mit `security definer`](https://supabase.com/docs/guides/database/functions) mit den Rechten ihres Besitzers läuft. Eine Beschränkung der Ausführungsberechtigung begrenzt nicht automatisch, wessen Zeilen die Funktion zurückgibt. Prüfe den Funktionscode und teste das Ergebnis aus Sicht des Aufrufers.

Erweitere eine Policy nicht bloß, damit eine fehlerhafte Ansicht wieder funktioniert. Kläre zuerst, ob ein fehlendes Grant, eine Besitzerbedingung, eine falsche Identität oder das falsche Deployment den Fehler verursacht. Wenn du die Ursache korrigierst, kann der erlaubte Ablauf funktionieren, ohne den ursprünglichen Zugriffsweg wieder zu öffnen.

## Wie prüfst du die bereitgestellte Anwendung erneut?

Teste die bereitgestellte Anwendung über jeden Datenzugriff, der zum Befund gehört, mit echten Anwendungsidentitäten und synthetischen Datensätzen. Halte die Antwort und jede dauerhafte Änderung fest. So prüfst du zugleich die Sitzungsverarbeitung, Konfiguration und den Code, der die Nutzer aktuell bedient.

Die [Testübersicht von Supabase](https://supabase.com/docs/guides/local-development/testing/overview) unterscheidet Datenbanktests von Anwendungstests über den tatsächlich eingesetzten Client. Übertrage dieselben erlaubten und verbotenen Fälle auf beide Ebenen. Eine Migration in Git dokumentiert die beabsichtigte Änderung. Prüfe zusätzlich, ob die Zielumgebung sie angewendet hat.

1. **Bestimme das Ziel.** Erfasse Projekt, Deployment-Revision, Migration und freigegebene Routen. Nutze getrennte Browserprofile oder Clients für A, B und Anfragen ohne Anmeldung. Eine gespeicherte Sitzung darf den Aufrufer nicht unbemerkt ändern.
2. **Lege kontrollierte Datensätze an.** Gib A und B eindeutig unterschiedliche synthetische Werte. Behalte einen erlaubten Lesezugriff bei, der die Existenz des Zieldatensatzes und die funktionierende Route bestätigt. Sammle keine unbeteiligten Kundendaten als Nachweis.
3. **Prüfe Lesen und Schreiben.** Teste Listen, direkte Datensatzanfragen sowie die tatsächlich vorgesehenen Create-, Update- und Delete-Aktionen. Prüfe die zurückgegebenen Felder. Bestätige nach einer abgewiesenen Schreiboperation, dass die ursprüngliche Zeile unverändert ist.
4. **Bewahre das Ergebnis auf.** Sichere bereinigte Anfragen und Antworten, die wirksame Identität, Zeilenzahlen und den Zustand vor und nach der Operation. Protokolliere fehlende oder abgelaufene Sitzungen getrennt vom Fall eines gültig angemeldeten, aber falschen Nutzers.

| Zugriffsweg | Grund für eine eigene Prüfung | Aufzubewahrender Nachweis |
| --- | --- | --- |
| Datenbank-View | [View-Besitzer und `security_invoker`](https://www.postgresql.org/docs/18/sql-createview.html) beeinflussen, wessen zugrunde liegende Rechte gelten. | A/B-Ergebnisse über die View und die Basistabelle |
| Dateispeicher | [Objekt-Policies](https://supabase.com/docs/guides/storage/security/access-control) steuern Storage-Operationen; [öffentliche Buckets erlauben jedoch öffentliche Downloads](https://supabase.com/docs/guides/storage/buckets/fundamentals). | Das beabsichtigte Listen-, Download- und Upload-Verhalten für kontrollierte Objekte |
| Edge Function | [Funktionsauthentifizierung und Client-Auswahl](https://supabase.com/docs/guides/functions/auth) bestimmen, ob Abfragen mit den Rechten des Aufrufers oder mit erhöhten Rechten laufen. | Geprüfter Aufrufer, erlaubte Aktion und Umfang der zurückgegebenen Datensätze |
| Export, Hintergrundjob oder Abonnement | Das Produkt kann einen weiteren Weg zu denselben Datensätzen anbieten. | Die entsprechende Besitzerprüfung und Ausgabe im vereinbarten Prüfbereich |

Nimm die Zugriffswege auf, die deine Anwendung bereitstellt, und kennzeichne ungeprüfte Wege als offen. Unser [Leitfaden zum Audit von Vibe-Coded Software](/de/blog/vibe-coded-software-audit/) erklärt, wie daraus ein vereinbarter Prüfauftrag mit konkreten Ergebnissen wird.

## Was prüft Lovables Sicherheitsscan?

Lovables Quick- und Deep-Sicherheitsscans untersuchen Code und Konfiguration in unterschiedlichem Umfang. Nutze die Befunde zusammen mit deiner Berechtigungsmatrix. Ein Scan kann weder jede Geschäftsregel festlegen noch belegen, dass dein A/B-Test an der bereitgestellten Anwendung ausgeführt wurde.

Laut [aktueller Sicherheitsübersicht](https://docs.lovable.dev/features/security) prüft Quick beim Veröffentlichen Datenzugriffseinstellungen, bekannte Schwachstellen in Abhängigkeiten und MCP-Zugriffe ohne Authentifizierung. Deep ergänzt die Analyse des Anwendungscodes und enthält Quick. Die eingebauten Scans analysieren Code und Konfiguration; optionale Penetrationstests zur Laufzeit sind davon getrennt. Deep kann auf Abruf, über Enterprise-Zeitpläne oder beim Veröffentlichen einer App mit unauthentifiziertem MCP-Zugriff starten.

Die [Security-Ansicht des Projekts](https://docs.lovable.dev/features/security-view) ordnet Befunde einer Codeversion zu. Wiederhole veraltete Scans und prüfe ignorierte Befunde, die in der Zahl offener Probleme fehlen. „No issues found“ bedeutet, dass der jüngste Scan nichts gefunden hat. Die Dokumentation sagt ausdrücklich, dass Scanner nicht jedes Risiko erkennen. Ob kritische Befunde die Veröffentlichung blockieren, hängt von den Workspace-Einstellungen ab.

Bewahre den Scan-Zeitpunkt und die geprüften Befunde zusammen mit den Ergebnissen der Nachprüfung auf. Kontrolliere automatisch geänderte Policies und führe den Regressionstest erneut aus. Für Änderungen von Menschen und Assistenten gelten dieselben Abnahmekriterien.

## Was tun, wenn vertrauliche Daten bereits abrufbar waren?

Wenn deine eigene Anwendung vertrauliche Daten an einen unberechtigten Aufrufer liefert, beschränke den betroffenen Zugriffsweg und beziehe die Verantwortlichen für Sicherheit und Datenschutz ein. Wir empfehlen, unmittelbare Eindämmung und Untersuchung zu trennen: Eine Zugriffsbeschränkung kann weitere Abrufe stoppen. Ob zuvor Daten abgerufen wurden, lässt sich aus einer bestandenen Nachprüfung allein nicht feststellen.

Sichere relevante Konfigurationen, den Deployment-Verlauf und vorhandene Logs, bevor Änderungen nützliche Spuren beseitigen. Dokumentiere, welche Datensätze und Operationen zum Befund gehören. Bewahre sensible Nachweise an einem kontrollierten Ort auf. Im Issue-Tracker sollten normalerweise synthetische Reproduktionen oder bereinigte Unterlagen liegen.

Stimme die Eindämmung mit dem Systemverantwortlichen ab: Beschränke eine exponierte Funktion, entferne ein unbeabsichtigtes Grant, pausiere die betroffene Funktionalität oder korrigiere ihre Policy. Wurde eine privilegierte Zugangsinformation offengelegt, mache sie nach dem Rotationsverfahren des Anbieters ungültig und beseitige zugleich die Offenlegung. Behandle einen öffentlichen Publishable Key entsprechend seiner vorgesehenen Rolle.

Eine leere Antwort nach dem Fix beweist nicht, dass die Daten vorher geschützt waren. Halte getrennt fest, wann der Fehler beobachtet wurde, wann die Eindämmung wirksam war und wann die Nachprüfung der bereitgestellten Anwendung bestand. Das verantwortliche Incident-Team kann Meldepflichten und weitere Verpflichtungen dann anhand der tatsächlichen Umstände beurteilen.

## Wann kannst du den Berechtigungsbefund schließen?

Schließe einen Berechtigungsbefund, wenn die vereinbarten Tests für erlaubte und verbotene Zugriffe an der bereitgestellten Anwendung bestehen, erlaubte Abläufe weiterhin funktionieren und die Nachweise die getestete Änderung sowie die Aufrufer benennen. Wir würden den Befund offen lassen, solange nur aktiviertes RLS, eine erfolgreiche Administratorabfrage oder ein grüner Scan ohne Nachprüfung auf Anwendungsebene vorliegt.

| Eintrag | Was du festhalten solltest |
| --- | --- |
| Beabsichtigte Grenze | A darf freigegebene Felder des eigenen privaten Datensatzes lesen und ändern; B und Aufrufer ohne Anmeldung dürfen das nicht. |
| Getestete Änderung | Deployment-Revision, Datenbankmigration sowie relevante Funktions- oder Policy-Definitionen |
| Beobachtetes Verhalten | Tatsächliche A/B/anon-Antworten, zurückgegebene Felder, betroffene Zeilen und unveränderter Zustand nach abgewiesenen Schreiboperationen |
| Offener Prüfbereich | Ungetestete Zugriffswege, Identitätstypen, Deployment-Unterschiede und die verantwortliche Person für die Nachprüfung |
| Abschlussentscheidung | Prüfer, Testdatum und der genau benannte geschlossene Befund, ohne Sicherheitszusage für die gesamte Anwendung |

Die [Cedars-Fallstudie zur technischen Bewertung](/de/case-studies/cedars/) beschreibt unsere Arbeit an Dokumentation, QA und einer abgegrenzten technischen Prüfung. Vereinbare die benötigten Nachweise vor Arbeitsbeginn. Über unseren [Penetrationstest-Service](/de/services/penetration-testing/) kannst du eine autorisierte Prüfung und Nachprüfung deiner laufenden Anwendung mit uns planen.

Nutze die [QA-Checkliste vor dem Software-Launch](/de/software-development-guide/software-qa-checklist-before-launch/) für die umfassendere Freigabeentscheidung. Für diesen Befund muss die erlaubte Anfrage gelingen und die verbotene Anfrage an derselben bereitgestellten Revision scheitern. Bewahre beide Ergebnisse auf, bevor du ihn schließt.

## Häufige Fragen zur Prüfung von Lovable-Datenzugriffen

### Schließt authenticated anonyme Supabase-Konten aus?

Nein. Eine anonyme Anmeldung bei Supabase Auth erzeugt einen Nutzer, der weiterhin die Datenbankrolle authenticated verwendet. Sein JWT enthält is_anonymous. Wenn dein Produkt dauerhafte Konten verlangt, setze diese Bedingung gesondert durch und teste sie. Unterscheide diese Identität von einer Anfrage ohne Anmeldung mit der Rolle anon: Beide Fälle durchlaufen unterschiedliche Zugriffsregeln.

### Beweist ein sichtbarer Supabase Publishable Key, dass ein Geheimnis offengelegt wurde?

Ein Publishable Key ist für öffentliche Anwendungsclients vorgesehen. Seine Sichtbarkeit allein belegt daher keine Offenlegung eines Geheimnisses. Prüfe den Schlüsseltyp und welche Daten Anfragen damit erreichen können. Secret Keys und ältere Service-Role-Zugangsdaten müssen anders behandelt und bei Offenlegung entfernt sowie rotiert werden. Einen Publishable Key zu verstecken korrigiert keine zu weit gefassten Datenrechte.

### Kann ich Kundenberechtigungen über eine Administratorverbindung testen?

Nutze bei Bedarf Administratorrechte, um kontrollierte Testdaten vorzubereiten. Prüfe das Kundenverhalten anschließend mit der richtigen wirksamen Rolle und Identität. Tabellenbesitzer und privilegierte Rollen können gewöhnliche Zeilen-Policies umgehen. Eine erfolgreiche Administratorabfrage bestätigt, dass ein Datensatz existiert. Die Abfrage belegt nicht, dass der für Kunden vorgesehene Zugriffsweg die beabsichtigte Beschränkung durchsetzt.

### Reicht eine leere API-Antwort als bestandener Test auf verweigerten Zugriff?

Erst wenn feststeht, dass die Anfrage die beabsichtigte Umgebung erreicht hat, der Datensatz existiert und der Aufrufer die vorgesehene Identität besitzt. Führe die erlaubte Besitzeranfrage als positive Kontrolle aus. Bei Schreiboperationen musst du zusätzlich den unveränderten gespeicherten Zustand bestätigen. Unterscheide im Testergebnis zwischen Berechtigungsfehlern, leeren gefilterten Ergebnissen und anderen Fehlern.

### Muss ich die App außerhalb von Lovable neu aufbauen?

Ein Neuaufbau ist nicht die Standardantwort auf einen einzelnen Datenzugriffsfehler. Identifiziere zuerst den betroffenen Weg, korrigiere seine Berechtigungsregel und prüfe das bereitgestellte Ergebnis. Ein größeres Architektur- oder Eigentumsproblem kann die Entscheidung verändern. Bewerte Wartbarkeit und Eigentum gesondert. Ein Frameworkwechsel belegt für sich genommen nicht, dass die neuen Berechtigungen funktionieren.

### Beweist ein RLS-Screenshot, dass die Produktionsumgebung getestet wurde?

Ein Screenshot kann einen Konfigurationszustand festhalten. Er benennt aber nicht jede anwendbare Policy, jeden Aufrufer oder jeden Datenzugriff. Dokumentiere das Ziel-Deployment und führe die vorgesehenen Anfragen mit kontrollierten Datensätzen aus. Bewahre erfolgreiche und abgewiesene Antworten einschließlich der Schreibergebnisse auf. Der Screenshot ergänzt die Verhaltensnachweise für den konkreten Befund.

### Kann das herunterladbare Testprojekt meine gehostete Supabase-App zertifizieren?

Nein. Das Testprojekt prüft synthetisches PostgreSQL-Policy-Verhalten in einer lokalen Laufzeit mit kontrolliertem Rollenkontext. Es authentifiziert keine echten Nutzer über Supabase und testet weder deine HTTP-API noch bereitgestellte Funktionen, Storage oder Anwendungskonfiguration. Nutze die Fälle als Ausgangspunkt und wiederhole die relevanten Prüfungen über die tatsächlichen Routen und Identitäten im vereinbarten Umfang.

QA und Produktionsreife

## Weiterlesen

Tests, Audits, Wartung und Härtung für verlässliche Produktionssoftware.

[Hier starten**QA für KI-generierten Code**](/de/blog/qa-for-ai-generated-code/)

- [Googles Elephant-Goldfish-Modell: Plan prüfen, dann Code](/de/blog/elephant-goldfish-model-design-review/)
- [LangSmith: Trace-Aufbewahrung, Sampling und Evaluationskosten](/de/blog/langsmith-trace-retention-sampling-cost/)
- [4 Softwareagenturen in Österreich für Entwicklung und QA (2026)](/de/blog/software-agencies-austria-development-qa/)
- [Ultramarine 1 Flash für Dokumenten-Agenten: Preise, API-Grenzen und Migrationstest](/de/blog/ultramarine-1-flash-api-document-workflows/)
- [Greptile Base, Plus oder Apex: PR-Reviews sinnvoll budgetieren](/de/blog/greptile-base-plus-apex-review-budget/)

[Nächster Artikel**Googles Elephant-Goldfish-Modell: Plan prüfen, dann Code**](/de/blog/elephant-goldfish-model-design-review/)

[**Zurück**](/de/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/)

[Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt

15 Min. Lesezeit · 4. November 2026 Zuletzt geprüft 4. November 2026

[**Weiter**](/de/blog/lovable-bolt-replit-app-due-diligence/)