KI-Check für Lovable
Lovable-App prüfen lassen, bevor echte Kunden kommen
Lovable bringt Sie in Tagen zu einer App, die aussieht wie ein fertiges Produkt. Ob sie sich auch so verhält, wenn echte Kunden ihre Daten eingeben, zeigt erst ein Blick in Code und Datenbank. Genau den machen wir.
Typische Befunde
Was wir in Lovable-Projekten oft finden
Offene Supabase-Tabellen
Row-Level Security fehlt oder erlaubt zu viel. Fremde können mit dem öffentlichen Schlüssel Daten lesen oder ändern.
Schlüssel im Browser-Code
API- oder Service-Schlüssel landen im Frontend und hebeln damit jede Zugriffsregel aus.
Logik nur im Frontend
Preise, Berechtigungen und Status werden im Browser geprüft – auf dem Server gar nicht.
Edge Functions ohne Prüfung
Serverfunktionen arbeiten mit erhöhten Rechten, ohne den Aufrufer zu verifizieren.
Riesige Komponenten
Einzelne Seiten mit hunderten Zeilen, in denen Daten, Logik und Darstellung verknotet sind.
Kein Staging, keine Migrationen
Änderungen gehen direkt auf die Produktivdatenbank, ohne versionierte Migrationen oder Testumgebung.
So prüfen wir Lovable-Apps
Lovable erzeugt eine React-Oberfläche, die direkt mit Supabase spricht. Die Sicherheit der App hängt deshalb weniger am Frontend als an der Datenbank: an Row-Level Security, Storage-Regeln und den Edge Functions. Dort setzen wir an.
- Datenbank und Regeln. Wir prüfen jede Tabelle, View und Funktion: Ist RLS aktiv, sind die Regeln für Lesen und Schreiben vollständig, und kann ein Kunde die Daten eines anderen sehen? Den ersten Teil davon können Sie selbst testen.
- Schlüssel und Konfiguration. Wir suchen im ausgelieferten Code und in der Git-Historie nach Schlüsseln, die dort nicht hingehören.
- Geschäftslogik. Wir prüfen, welche Regeln nur im Browser durchgesetzt werden und auf den Server gehören – Preise, Rollen, Limits.
- Architektur. Wie gut lässt sich die App weiterentwickeln? Gibt es ein Datenmodell für Firmenkunden, oder nur einzelne Logins? Mehr dazu im Artikel zur Architektur von KI-Apps.
- Betrieb. Backups, Testumgebung, Migrationen, Monitoring – das, was Lovable nicht von sich aus mitbringt.
Was Sie bekommen
Im Quick-Check (3 Arbeitstage) eine Ampel pro Bereich und unsere Empfehlung, ob sich ein Deep-Dive lohnt. Im Deep-Dive einen Bericht mit jedem Befund, seiner Fundstelle und einer priorisierten Roadmap – geordnet nach Ihrem Ziel: einsatzbereit, skalierbar oder kommerzialisierbar. Wie das aussieht, zeigt der Musterbericht.
Warum das wichtig ist
Lücken in den Zugriffsregeln von Lovable-Projekten sind kein theoretisches Risiko. Sie waren so verbreitet, dass sie eine eigene Sicherheitsmeldung erhielten: CVE-2025-48757, Schweregrad 9,3 von 10. Lovable bestreitet die Einstufung und verweist auf die Verantwortung der App-Betreiber – was die Frage, wer die eigene App prüft, nur noch wichtiger macht.
Häufige Fragen
Müssen wir Lovable verlassen?
Nein. Viele Befunde lassen sich innerhalb von Lovable und Supabase beheben. Wir sagen Ihnen ehrlich, ab welchem Punkt ein Weiterentwickeln ausserhalb von Lovable sinnvoller ist – zum Beispiel bei komplexer Geschäftslogik oder mehreren Entwicklern.
Wie bekommen Sie Zugriff auf den Code?
Über die GitHub-Synchronisation von Lovable: Sie geben uns Lesezugriff auf das Repository. Für die Datenbank reicht für den Quick-Check meist ein Export des Schemas und der Regeln – Zugriff auf echte Kundendaten brauchen wir nicht.
Können Sie die Befunde auch beheben?
Ja. Nach dem Bericht entscheiden Sie: selbst umsetzen (der Bericht ist dafür geschrieben) oder uns mit einer Offerte für die Umsetzung beauftragen.
Meine App hat noch keine Kunden. Lohnt sich der Check schon?
Gerade dann. Zugriffsregeln und Datenmodell sind vor dem Launch in Stunden korrigiert – mit Kundendaten in der Datenbank wird jede Änderung aufwendiger und riskanter.