Ist das ein Penetrationstest?

Nein. Veriploy ist eine laufende technische Prüfung von Repo, Security, CVEs und Infrastruktur, kein klassischer Pentest. Bei Lovable-Apps schauen wir als Lovable Security Audit besonders auf Supabase, RLS und Secrets. Ein Pentest kann das ergänzen, wenn gezielt Angriffe simuliert werden sollen.

Macht ihr auch die Fixes?

Im Abo nicht. Wir prüfen, priorisieren und erklären, was zu tun ist, etwa wie eine RLS-Policy aussehen sollte oder wie ein Schlüssel sauber serverseitig landet. Die Umsetzung läuft separat über Wevelsiep Advisory bzw. WZ-IT oder das eigene Team. So bleibt die Prüfung unabhängig von der Umsetzung.

Braucht ihr Repo-Zugriff?

Ja, standardmäßig read-only. Lesezugriff auf das Repository und ein Blick in die Supabase-Konfiguration reichen für die Prüfung. Schreibrechte brauchen wir nicht, weil wir die Fixes nicht selbst committen.

Ersetzt das den Lovable-Security-Scan?

Nein, es ergänzt ihn. Der Lovable-Scan findet Findings, das ist ein guter Anfang. Ich ordne ein, welche davon vor echten Nutzern produktionskritisch sind, und behalte Repo, CVEs und Infrastruktur danach laufend im Blick. Scanner und menschliche Priorisierung arbeiten zusammen.

Der Einstieg ist fest kalkuliert: Baseline 790 € einmalig. Laufende Aufsicht startet bei 990 € pro Monat (Oversight), weiter mit Guard 1.950 € und Launch 3.900 € pro Monat. Alle Preise netto zzgl. USt. Laufende Pakete starten mit 3 Monaten Mindestlaufzeit, danach monatlich kündbar, sofern nicht anders vereinbart.

Lovable prüfen

Lovable-App prüfen lassen, bevor Supabase, RLS oder Secrets zum Risiko werden

Lovable baut die App in Stunden, und sie funktioniert. Ob sie auch produktionsreif ist, entscheidet sich an Supabase, RLS und Secrets. Ich prüfe genau diese Punkte als Lovable Security Audit, ordne ein, was wirklich kritisch ist, und behalte Repo, CVEs und Infrastruktur danach laufend technisch im Blick.

Pakete ansehen

Baseline ab 790 €
Supabase, RLS und Secrets im Fokus
Repo + CVE + Infrastruktur
Deutscher Ansprechpartner

Direkter Ansprechpartner

Timo Wevelsiep

Softwareentwickler, Cloud-Architekt, Gründer & Geschäftsführer

Ich prüfe Code, Security und Infrastruktur und mache sichtbar, was vor Launch, Kundeneinsatz oder Due Diligence technisch riskant ist.

Ich habe produktive Software-, Infrastruktur- und Cloud-Systeme für Kunden weltweit begleitet, darunter Europa, VAE, Asien, Australien und Amerika: von automatisierten Standortplattformen über Cloud-Migrationen bis zu Remote-Access-Systemen für Industrieanlagen.

Für Fragen wie:

Ist dieser Release produktionsreif?
Welche CVEs sind wirklich kritisch?
Sind Auth, Datenzugriff und Tenant-Isolation sauber?

Lovable-Apps funktionieren schnell, aber Production hat eigene Regeln

Lovable bringt das Team in Rekordzeit zu einer App, die im Demo läuft. Genau diese Geschwindigkeit überspringt aber Entscheidungen, die erst vor echten Nutzern zum Problem werden. Diese Lücken sehen wir bei Lovable-Apps am häufigsten:

Login ist vorhanden, aber der Zugriff auf Daten ist nicht abgesichert
Supabase-RLS deaktiviert oder mit zu großzügigen Policies
Schlüssel im Frontend-Bundle, das jeder Besucher lesen kann
serverseitige Validierung fehlt, der Client gilt als vertrauenswürdig
Edge Functions ohne Auth-Prüfung oder Eingabevalidierung
Deployment ohne Security-Header, CORS-Regeln und Rate Limits
kein Monitoring, kein Logging und kein Backup-Plan
Dependencies mit bekannten CVEs, die niemand mehr aktualisiert

Supabase und RLS: Login ist nicht Zugriffsschutz

Lovable bindet Supabase als Backend ein, und das Login funktioniert auf Anhieb. Daraus folgt aber nicht, dass Daten geschützt sind. Authentifizierung beantwortet nur die Frage, wer jemand ist. Autorisierung beantwortet, was diese Person sehen und ändern darf. Genau diese zweite Ebene liegt bei Supabase in den Row-Level-Security-Policies, und die werden beim schnellen Bauen oft nicht oder unvollständig gesetzt.

Ist RLS deaktiviert, kann ein eingeloggter Nutzer über die offen erreichbare API mehr abfragen als die Oberfläche zeigt. Die Tabelle gibt dann Zeilen aus, die eigentlich anderen Tenants gehören. Auch aktivierte, aber zu weite Policies sind ein Risiko: Eine Regel, die nur prüft, ob jemand eingeloggt ist, trennt keine Mandanten voneinander.

Wir prüfen, ob RLS auf allen relevanten Tabellen aktiv ist, ob die Policies pro Nutzer oder pro Tenant tatsächlich isolieren und ob es Tabellen gibt, die versehentlich offen erreichbar sind. Jeden Befund ordnen wir nach Schweregrad ein, sodass sichtbar wird, was wirklich produktionskritisch ist.

Secret-Handling: anon key, service_role key und Drittanbieter-Schlüssel

Bei Supabase gibt es zwei Schlüssel mit sehr unterschiedlicher Tragweite. Der anon key gehört bewusst ins Frontend und ist nur in Kombination mit aktiven RLS-Policies sicher. Der service_role key umgeht RLS komplett und darf niemals im Client landen. Genau diese Verwechslung passiert beim schnellen Bauen, und dann liegt ein Schlüssel mit Vollzugriff im Bundle, das jeder Besucher öffnen kann.

Dazu kommen Schlüssel von Drittanbietern: OpenAI-Keys für KI-Features, Stripe-Secrets für Zahlungen, Tokens für E-Mail oder Storage. Landen diese im Client oder im Repository, kann sie jemand auslesen und auf Rechnung des Betreibers nutzen. Bei Zahlungs- und KI-APIs wird daraus schnell ein direkter finanzieller Schaden.

Wir suchen Schlüssel im Frontend-Bundle, in der Git-Historie und in der Konfiguration, prüfen, ob der service_role key sicher serverseitig bleibt, und zeigen, welche Aufrufe über eine Edge Function statt direkt aus dem Browser laufen sollten.

Edge Functions und serverseitige Validierung

Sobald eine Lovable-App mehr tut als Daten anzeigen, kommen Supabase Edge Functions ins Spiel: für Zahlungen, KI-Aufrufe oder Aktionen, die nicht im Browser passieren dürfen. Eine Edge Function ist aber nur dann ein Schutz, wenn sie selbst prüft, wer aufruft und mit welchen Daten. Sonst verlagert sie das Problem nur vom Client auf den Server.

Typisch ist, dass die Funktion die Identität des Aufrufers nicht erneut prüft, Eingaben ungeprüft an die Datenbank oder an einen Drittanbieter weiterreicht oder davon ausgeht, dass nur die eigene Oberfläche sie aufruft. Wer den Endpunkt kennt, kann ihn aber direkt ansprechen. Serverseitige Validierung bedeutet, dass die Funktion jeder Eingabe misstraut, unabhängig davon, woher der Aufruf kommt.

Wir schauen, ob Edge Functions Auth korrekt prüfen, Eingaben validieren und den service_role key nur dort verwenden, wo es nötig ist, und ob kritische Aktionen wirklich serverseitig statt im Browser entschieden werden.

Deployment: Header, CORS, Rate Limits, Monitoring und Backups

Eine funktionierende App ist noch keine betriebssichere App. Das, was zwischen Deploy und echtem Betrieb liegt, fehlt bei Lovable-Projekten oft komplett. Wir prüfen diese Betriebsebene mit:

Security-Header wie Content-Security-Policy und HSTS gesetzt
CORS-Regeln eng gefasst statt auf alle Ursprünge geöffnet
Rate Limits an Login-, API- und Edge-Function-Endpunkten
Monitoring und Logging, damit Fehler und Angriffe sichtbar werden
Backups der Supabase-Datenbank mit getestetem Wiederherstellungsweg
Trennung von Umgebungen, damit Test- und Live-Daten nicht vermischt sind

Was Lovable-Scans leisten und wo Veriploy ergänzt

Lovable bringt eigene Sicherheitschecks mit, und die sind ein guter Anfang. Ein Scanner findet viele Findings: er meldet eine fehlende Policy, einen exponierten Schlüssel oder eine veraltete Dependency. Was ein Scanner nicht leistet, ist die Einordnung, wie sie ein manuelles Lovable Code Review liefert. Er sagt nicht, welcher der Befunde das Produkt vor echten Nutzern wirklich gefährdet und welcher warten kann.

Genau hier setzt Veriploy an. Wir nehmen die Findings, ordnen sie nach Produktionskritikalität ein und übersetzen sie in eine klare Reihenfolge: was sofort behoben werden muss, was vor dem nächsten Release wichtig ist und was unkritisch bleibt. Diese menschliche Priorisierung ersetzt den Lovable-Scan nicht, sie macht ihn nutzbar.

Und weil Lovable-Apps sich mit jedem Prompt verändern, bleibt es nicht bei einem Einmal-Blick. Die App wird einmal geprüft (Baseline) und danach bleiben Repo, CVEs und Infrastruktur laufend technisch im Blick, mit Oversight, Guard oder Launch. So bleibt die Risikoampel aktuell, statt mit dem nächsten Feature zu veralten.

Ablauf

So läuft der Lovable-Review ab

01
Lovable-Kontext klären
Zuerst wird geklärt, wie die App gebaut wurde: Lovable-Projekt, Supabase-Projekt, Auth, Tabellen, Edge Functions, Storage, Payments, Nutzerrollen und geplanter Launch.
02
Repo, Supabase und Deployment einordnen
Ich prüfe, wie Frontend, Supabase, Datenbankregeln, Edge Functions und Deployment zusammenspielen. Besonders wichtig: Welche Logik läuft im Client, welche serverseitig, und wo liegen Secrets?
03
RLS, Auth und Datenzugriff prüfen
Bei Lovable-Apps liegt das größte Risiko oft nicht im UI-Code, sondern in falschen oder fehlenden Supabase-RLS-Policies, Storage-Regeln, service_role-Nutzung oder zu breiten Datenbankzugriffen.
04
Findings und Prioritäten
Es entstehen konkrete Findings wie: RLS fehlt, Storage Bucket öffentlich, Auth prüft Login aber keine Rolle, service_role Key falsch eingesetzt, API-Endpunkt ohne Validierung.
05
Launch- oder Abo-Empfehlung
Danach ist klar, ob eine Baseline reicht oder ob das Projekt laufend mit Guard oder Launch begleitet werden sollte.

Viele Projekte starten mit einem Baseline-Review. Wird das Produkt danach weiter mit AI entwickelt, kann Veriploy es laufend begleiten.

Was ich für den Review brauche

Read-only-Zugriff auf das Repository
kurze Beschreibung von Stack, Tool und Ziel
Infos zu Hosting und Deployment
Datenbank- und Auth-Kontext
Hinweise auf sensible Daten oder Nutzerrollen
offene Fragen oder konkrete Sorgen

Was der Review liefert

verständliche Risikoampel
Top-Risiken auf einen Blick
priorisierte Findings
konkrete Handlungsempfehlungen
Einordnung: jetzt fixen, vor Launch fixen, später einplanen
optionale Empfehlung für Oversight, Guard oder Launch

Beispielbefund

So sieht ein Befund aus

veriploy-reportKritisch

RLS-01Tenant-Isolation

Supabase-RLS für Tabelle invoices unvollständig, Nutzer könnten fremde Rechnungen sehen. Empfehlung: Policy pro user_id erzwingen.

Vergleich

Lovable-Scan oder laufende Aufsicht durch Veriploy?

	Lovable-Scan	Veriploy laufend
Ergebnis	Liste an Findings ohne Reihenfolge	Findings nach Produktionskritikalität einsortiert
RLS und Secrets	Automatisch erkannt, soweit Muster greifen	Manuell geprüft auf echte Tenant-Isolation
CVEs und Dependencies	Stand des Scan-Laufs	Laufendes Monitoring mit Hinweisen
Infrastruktur und Betrieb	Nur eingeschränkt im Blick	Header, CORS, Rate Limits, Backups mitgeprüft
Vor dem Release	Erneuter Scan nötig	Menschliche Einschätzung im Paket enthalten

FAQ

Häufige Fragen

Ist das ein Penetrationstest?
Nein. Veriploy ist eine laufende technische Prüfung von Repo, Security, CVEs und Infrastruktur, kein klassischer Pentest. Bei Lovable-Apps schauen wir als Lovable Security Audit besonders auf Supabase, RLS und Secrets. Ein Pentest kann das ergänzen, wenn gezielt Angriffe simuliert werden sollen.
Macht ihr auch die Fixes?
Im Abo nicht. Wir prüfen, priorisieren und erklären, was zu tun ist, etwa wie eine RLS-Policy aussehen sollte oder wie ein Schlüssel sauber serverseitig landet. Die Umsetzung läuft separat über Wevelsiep Advisory bzw. WZ-IT oder das eigene Team. So bleibt die Prüfung unabhängig von der Umsetzung.
Braucht ihr Repo-Zugriff?
Ja, standardmäßig read-only. Lesezugriff auf das Repository und ein Blick in die Supabase-Konfiguration reichen für die Prüfung. Schreibrechte brauchen wir nicht, weil wir die Fixes nicht selbst committen.
Ersetzt das den Lovable-Security-Scan?
Nein, es ergänzt ihn. Der Lovable-Scan findet Findings, das ist ein guter Anfang. Ich ordne ein, welche davon vor echten Nutzern produktionskritisch sind, und behalte Repo, CVEs und Infrastruktur danach laufend im Blick. Scanner und menschliche Priorisierung arbeiten zusammen.
Was kostet das?
Der Einstieg ist fest kalkuliert: Baseline 790 € einmalig. Laufende Aufsicht startet bei 990 € pro Monat (Oversight), weiter mit Guard 1.950 € und Launch 3.900 € pro Monat. Alle Preise netto zzgl. USt. Laufende Pakete starten mit 3 Monaten Mindestlaufzeit, danach monatlich kündbar, sofern nicht anders vereinbart.

Passende Themen

Erkennst du diese Risiken in der eigenen App?

Der AI-App Risiko-Self-Check ordnet Produktstatus, Stack, Auth, Datenzugriff, Infrastruktur, CVEs und deinen technischen Kenntnisstand ein und zeigt, ob ein Review sinnvoll ist.

Risiko-Self-Check starten

Lovable-App prüfen lassen und danach im Blick behalten.

Der Einstieg erfolgt mit der Baseline, danach laufende Aufsicht im passenden Paket.

Pakete ansehen

Repo-Fit

Repo-Fit prüfen

Kurz das Projekt beschreiben.

Direkter Kontakt zu mir, kein anonymes Ticket-System. Ich melde mich mit einer ersten Einschätzung und dem passenden Einstieg.