Reicht es nicht, wenn Supabase Auth aktiv ist?

Nein. Auth klärt nur, wer eingeloggt ist. Welche Zeilen dieser Nutzer lesen oder ändern darf, entscheidet die RLS-Policy. Ohne aktive und korrekt eingeschränkte Policies kann ein eingeloggter oder sogar anonymer Request mehr sehen als vorgesehen. Wir prüfen genau diese Autorisierung pro Tabelle und Operation.

Prüft ihr auch Storage Buckets und Edge Functions?

Ja. Das RLS-Review hört nicht bei den Tabellen auf. Wir prüfen, ob Storage Buckets und Datei-Policies gegen anonymen Zugriff abgesichert sind und ob der service_role-Key wirklich nur serverseitig und kontrolliert genutzt wird, nicht im Frontend oder ungeschützt in Edge Functions.

Behebt ihr die Policies auch selbst?

Im Abo nicht. Wir prüfen, priorisieren und erklären, welche Policy fehlt oder zu breit ist und wie sie aussehen sollte. Die Umsetzung läuft über das interne Team oder separat über Wevelsiep Advisory bzw. WZ-IT. So bleibt die Prüfung unabhängig von der Umsetzung.

Was braucht ihr für das Review?

Lesezugriff auf das Repository und Einblick in das Datenbankschema samt Policies. Schreibrechte auf der Produktivdatenbank brauchen wir nicht. Für die reproduzierbaren Tests reicht in der Regel eine Test- oder Staging-Umgebung.

Was kostet ein Supabase-RLS-Review?

Der Einstieg ist fest kalkuliert: Baseline 790 € einmalig, das RLS-Review ist Teil des Baseline-Checks. 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.

Was hat CVE-2025-48757 damit zu tun?

Dieser Fall zeigt, wie real unvollständige RLS wird: Über hundert Low-Code-Apps hatten Tabellen, die ohne Login über den anon-Key lesbar waren, laut CVE-Record als kritisch eingestuft (CVSS 9.3). Ursache war Fehlkonfiguration, kein Supabase-Bug. Genau dieses Muster prüfen wir und behalten es laufend im Blick.

Supabase RLS

Supabase RLS prüfen lassen, bevor Nutzerdaten über falsche Policies offenliegen

Row Level Security entscheidet, wer welche Zeile sehen darf. Eine einzige zu breite Policy reicht, damit fremde Nutzer fremde Daten lesen. Als Supabase Security Audit von Veriploy prüfe ich die Supabase-RLS des Produkts über Tabellen, Auth, Storage und Edge Functions und behalte sie danach laufend technisch im Blick, statt es bei einem Einmal-Blick zu belassen.

Pakete ansehen

Baseline-Check 790 €
Policies + Auth + Storage
Reproduzierbare Tests
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?

Was Row Level Security in Supabase ist

Row Level Security (RLS) ist die Zugriffskontrolle direkt in der Postgres-Datenbank. Statt im Frontend oder in der API zu entscheiden, wer was sieht, legen RLS-Policies pro Tabelle und pro Operation fest, welche Zeilen ein Nutzer lesen oder schreiben darf. So entscheidet sie über Datentrennung:

01Policies gelten auf Zeilenebene, nicht nur pro Tabelle

02getrennte Regeln für select, insert, update und delete

03Auswertung über auth.uid() und die JWT-Claims des Requests

04der anon-Key trifft auf die gleichen Policies wie eingeloggte Nutzer

05ohne aktivierte RLS ist eine Tabelle über den anon-Key offen lesbar

Warum Authentifizierung nicht gleich Autorisierung ist

Authentifizierung beantwortet die Frage, wer jemand ist. Autorisierung beantwortet die Frage, was diese Person sehen und ändern darf. Viele Supabase-Projekte lösen das Erste sauber über Supabase Auth und nehmen an, dass damit auch das Zweite erledigt sei. Das ist nicht der Fall.

Ein gültiges Login bedeutet nur, dass ein Request einen echten Nutzer trägt. Ob dieser Nutzer dann auf die Rechnungen, Nachrichten oder Dateien eines anderen Mandanten zugreifen kann, entscheidet allein die RLS-Policy. Fehlt sie oder ist sie zu breit gefasst, sieht jeder eingeloggte Nutzer, und im schlimmsten Fall jeder anonyme Request, mehr als vorgesehen.

Genau hier setzt unser Review an: Wir prüfen nicht nur, ob Auth funktioniert, sondern ob die Autorisierung pro Zeile und pro Operation wirklich greift, bis hinunter auf die Policy-Bedingung.

Häufige RLS-Fehler, die wir finden

RLS ist mächtig, aber leicht falsch konfiguriert. Per rohem SQL oder über den SQL-Editor angelegte Tabellen haben RLS standardmäßig aus, über den Table Editor erstellte sind per Default aktiviert. Diese Lücken sehen wir am häufigsten:

Fehler	Was dadurch passiert
RLS nicht aktiviert	Die Tabelle ist über den anon-Key vollständig lesbar, ohne Login.
Zu breite select-Policies	Bedingungen wie true oder fehlende user_id-Prüfung geben jede Zeile frei.
Fehlende insert/update/delete-Einschränkung	Lesen ist abgesichert, aber Nutzer können fremde oder beliebige Datensätze schreiben.
Storage Buckets öffentlich	Dateien wie Uploads oder Belege sind ohne Storage-Policy frei abrufbar.
service_role-Key im falschen Kontext	Der Key umgeht RLS komplett und landet im Frontend oder wird in Edge Functions ohne eigene Auth- und Eingabeprüfung genutzt.
Tenant-ID nur im Frontend geprüft	Die Mandantentrennung lässt sich durch manipulierte Requests einfach umgehen.

Was ich im RLS-Review prüfe

Wir gehen die Zugriffskette systematisch durch, von der Tabelle bis zur Edge Function, und ordnen jeden Befund nach Schweregrad ein. So lässt sich ein Supabase Datenleck verhindern, bevor falsche Policies Nutzerdaten offenlegen. Geprüft werden:

Tabellen: ist RLS überall aktiviert, wo Nutzerdaten liegen
Policies: sind select, insert, update und delete sauber und nicht zu breit
Auth: greifen auth.uid() und JWT-Claims wie erwartet pro Rolle
Storage: sind Buckets und Datei-Policies gegen anonymen Zugriff abgesichert
Edge Functions: wird der service_role-Key nur serverseitig und kontrolliert genutzt
Tests: reproduzierbare Checks, die anonyme und mandantenübergreifende Zugriffe gezielt versuchen

Konkretes Muster: CVE-2025-48757

Wie real unvollständige RLS wird, zeigt CVE-2025-48757. Im Mai 2025 dokumentierte ein Sicherheitsforscher, dass über hundert mit einem Low-Code-Tool gebaute Apps Supabase-Tabellen hatten, die sich über den öffentlichen anon-Key ohne Login lesen, teils auch schreiben ließen. Die Schwachstelle wurde laut CVE-Record als kritisch eingestuft (CVSS 9.3), Kategorie Incorrect Authorization.

Wichtig zur Einordnung: Das war kein Bug in Supabase selbst. Die Ursache lag in der Konfiguration der generierten Apps, fehlende oder zu breite RLS-Policies auf Tabellen, deren RLS standardmäßig aus war. Supabase stellt RLS bereit, aber ob sie pro Tabelle und Operation korrekt greift, entscheidet die jeweilige App.

Genau dieses Muster, automatisch generierter Code plus angenommene, aber nicht überprüfte Datentrennung, ist der Grund, warum wir RLS nicht einmalig abhaken, sondern laufend im Blick behalten. Jede neue Tabelle und jede geänderte Policy kann die Trennung wieder aufweichen.

Ablauf

So läuft der Supabase-RLS-Review ab

01
Datenmodell und Mandantenlogik verstehen
Zuerst wird geklärt, welche Tabellen sensible Daten enthalten, wie Nutzer, Teams, Organisationen oder Mandanten abgebildet sind und welche Rollen auf welche Daten zugreifen dürfen.
02
Policies, Auth und Storage prüfen
Ich prüfe RLS-Aktivierung, Select-, Insert-, Update- und Delete-Policies, Storage-Buckets, Edge Functions, service_role-Nutzung und die Trennung zwischen Authentifizierung und Autorisierung.
03
Zugriffsszenarien testen
Typische Szenarien werden nachvollzogen: Nutzer A darf nicht Daten von Nutzer B sehen, Team-Mitglieder dürfen nur eigene Organisationen sehen, Admin-Endpunkte brauchen echte Rollenprüfung.
04
Risikoampel und konkrete Findings
Ergebnis ist eine klare Einschätzung: Welche Policies sind kritisch, welche Daten könnten offenliegen, welche Regeln sind zu breit und was sollte vor Launch angepasst werden?
05
Umsetzung oder laufende Aufsicht
Kritische RLS-Findings können anschließend separat umgesetzt oder im Rahmen von Guard oder Launch laufend beobachtet werden.

Viele Projekte starten mit einem Baseline-Review. Wird das Produkt danach weiter mit AI entwickelt, kann ich 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-01Row Level Security

RLS für Tabelle messages nicht aktiviert, Inhalte über den anon-Key ohne Login lesbar. Empfehlung: RLS aktivieren und select-Policy auf auth.uid() = user_id erzwingen.

Vergleich

Einmal-Blick auf die RLS oder laufende Aufsicht?

	Einmal-Blick	Veriploy laufend
Zeitpunkt	Momentaufnahme zu einem Stichtag	Fortlaufend, mit jeder neuen Tabelle und Policy
Neue Tabellen	Nicht abgedeckt, RLS bleibt oft aus	Neue Tabellen ohne aktive RLS fallen früh auf
Policy-Änderungen	Werden nicht erneut geprüft	Zu breite Änderungen werden kommentiert
Storage und Edge Functions	Selten mitgeprüft	Buckets und service_role-Nutzung im Blick
Einordnung	Liste zum Abschluss	Menschliche Priorisierung statt nur Score

FAQ

Häufige Fragen

Reicht es nicht, wenn Supabase Auth aktiv ist?
Nein. Auth klärt nur, wer eingeloggt ist. Welche Zeilen dieser Nutzer lesen oder ändern darf, entscheidet die RLS-Policy. Ohne aktive und korrekt eingeschränkte Policies kann ein eingeloggter oder sogar anonymer Request mehr sehen als vorgesehen. Wir prüfen genau diese Autorisierung pro Tabelle und Operation.
Prüft ihr auch Storage Buckets und Edge Functions?
Ja. Das RLS-Review hört nicht bei den Tabellen auf. Wir prüfen, ob Storage Buckets und Datei-Policies gegen anonymen Zugriff abgesichert sind und ob der service_role-Key wirklich nur serverseitig und kontrolliert genutzt wird, nicht im Frontend oder ungeschützt in Edge Functions.
Behebt ihr die Policies auch selbst?
Im Abo nicht. Wir prüfen, priorisieren und erklären, welche Policy fehlt oder zu breit ist und wie sie aussehen sollte. Die Umsetzung läuft über das interne Team oder separat über Wevelsiep Advisory bzw. WZ-IT. So bleibt die Prüfung unabhängig von der Umsetzung.
Was braucht ihr für das Review?
Lesezugriff auf das Repository und Einblick in das Datenbankschema samt Policies. Schreibrechte auf der Produktivdatenbank brauchen wir nicht. Für die reproduzierbaren Tests reicht in der Regel eine Test- oder Staging-Umgebung.
Was kostet ein Supabase-RLS-Review?
Der Einstieg ist fest kalkuliert: Baseline 790 € einmalig, das RLS-Review ist Teil des Baseline-Checks. 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.
Was hat CVE-2025-48757 damit zu tun?
Dieser Fall zeigt, wie real unvollständige RLS wird: Über hundert Low-Code-Apps hatten Tabellen, die ohne Login über den anon-Key lesbar waren, laut CVE-Record als kritisch eingestuft (CVSS 9.3). Ursache war Fehlkonfiguration, kein Supabase-Bug. Genau dieses Muster prüfen wir und behalten es laufend im Blick.

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

Supabase-RLS-Review im Baseline-Check, bevor Daten offenliegen.

Der Baseline-Check ist der Einstieg, danach bleiben Policies, Storage und Edge Functions laufend im Blick.

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.