Sicherheits-Checkliste für Lovable-Apps: Ist Ihre App sicher?

Ist Lovable sicher, und macht das meine App sicher?

Lovable gibt an, SOC-2- und DSGVO-Anforderungen zu unterstützen, und veröffentlicht seine Sicherheitsdokumentation im eigenen Trust Center. Das betrifft die Plattform von Lovable: ihre Infrastruktur, ihre Zugriffskontrollen, ihr Personal. Es betrifft nicht die Regeln in Ihrer App, denn die haben Sie (mit Hilfe von Lovable) geschrieben.

Lovables Sicherheitsscan führt bei jeder Veröffentlichung eine schnelle Prüfung aus: eine Datenbankprüfung, eine Prüfung der Abhängigkeiten und eine MCP-Server-Prüfung. Ein tieferer Scan, manuell gestartet (oder für Lovable-Enterprise-Kunden nach Zeitplan), prüft zusätzlich Zugriffskontrolle, nicht authentifizierte Endpoints, Injection, geleakte Secrets, Zahlungen, Authentifizierung und offengelegte personenbezogene Daten. Lovables eigene Dokumentation stellt klar, dass diese Werkzeuge keine vollständige Sicherheit garantieren können. Betrachten Sie den Scan als Rauchmelder, nicht als Inspektion.

Was war CVE-2025-48757, und betrifft es meine App?

CVE-2025-48757, veröffentlicht im Mai 2025, beschreibt unzureichende Row-Level-Security-Richtlinien in von Lovable generierten Websites bis zum 15. April 2025, die es nicht authentifizierten Angreifern erlaubten, Datenbanktabellen zu lesen oder zu schreiben. Die National Vulnerability Database der USA führt sie mit einem kritischen CVSS-3.1-Wert von 9,3 und vermerkt, dass Lovable sie bestreitet, mit der Begründung, dass jeder Kunde selbst für den Schutz der Daten seiner App verantwortlich ist.

Der Forscher, der sie gemeldet hat, Matt Palmer, sagt, er habe 1.645 Projekte gescannt und 303 verwundbare Endpoints in 170 davon gefunden, und Lovable habe seinen Sicherheitsscan im April 2025 mit Lovable 2.0 eingeführt. Wie auch immer Sie den Streit bewerten, die praktische Lehre ist dieselbe: Wenn Ihre App vor diesem Zeitpunkt generiert wurde oder Sie seitdem Tabellen geändert haben, prüfen Sie Ihre Richtlinien selbst. Eine Richtlinie, die existiert, ist nicht dasselbe wie eine Richtlinie, die stimmt.

Was sollte eine Sicherheits-Checkliste für Lovable abdecken?

Wie behebe ich Supabase-RLS-Fehler in einer Lovable-App?

RLS-Fehler gibt es in zwei gegensätzlichen Arten, und es hilft zu wissen, welche Sie haben.

• Permission denied (Postgres-Fehler 42501 oder ein leeres Ergebnis). RLS ist an, und keine Richtlinie erlaubt die Anfrage. Das ist RLS, das funktioniert. Schreiben Sie die engste Richtlinie, mit der die Funktion läuft, zum Beispiel Zeilen, bei denen die Owner-Spalte der ID des angemeldeten Nutzers entspricht.
• Alles funktioniert für alle. Der gefährlichere Fall. Eine Richtlinie wie USING (true) oder ein fehlender RLS-Schalter lässt jeden Nutzer durch. Der Advisor von Supabase markiert zu freizügige Richtlinien (Lint 0024, permissive_rls_policy) und Richtlinien, die existieren, während RLS aus ist (Lint 0007, policy_exists_rls_disabled).
• Richtlinien, die Nutzer-Metadaten lesen. Supabase warnt davor, Richtlinien auf Metadaten zu stützen, die ein Nutzer selbst bearbeiten kann (Lint 0015, rls_references_user_metadata). Nutzen Sie stattdessen eine Tabelle, die Ihr Server kontrolliert, etwa eine Tabelle der Teammitgliedschaften.

Wenn Sie Lovable bitten, eine Richtlinie zu reparieren, führen Sie den Zwei-Nutzer-Test danach erneut aus. Ein Prompt, der einen Fehler verschwinden lässt, kann das tun, indem er den Zugriff erweitert – genau der Fehler, den Sie verhindern wollen.

Welche Keys dürfen in einer Lovable-App offengelegt werden?

Laut Supabase-Dokumentation darf der Publishable-(Anon-)Key offengelegt werden, weil er nur erreicht, was Row-Level Security erlaubt. Ein Secret Key, einschließlich des Service-Role-Keys, umgeht jede RLS-Richtlinie und darf niemals in einen Browser, eine ausgelieferte App oder die Versionsverwaltung gelangen. Der Glossareintrag zu Anon-Key und Service-Role-Key erklärt den Unterschied. Secrets von Drittanbietern, etwa Keys von Stripe oder dem E-Mail-Anbieter, gehören in die Secrets der Edge Functions, nicht in den Code der App. Siehe Secrets-Management.

Wie oft sollte eine Live-Lovable-App erneut geprüft werden?

Nach jeder Änderung an Daten, Zugriffen oder Zahlungen, und für alles andere nach Zeitplan: Abhängigkeiten bekommen neue Schwachstellen, Keys sollten rotiert werden, und neue Tabellen kommen mit neuen Richtlinien. Darum funktioniert Sicherheit besser als Gewohnheit denn als Audit. In unseren Plänen laufen Sicherheitsprüfungen, Code-Review und Regressionstests bei jeder Änderung, bevor sie die Produktion erreicht, und ein anderer Entwickler als der Autor gibt sie frei.