Vibe-Code Rescue · Supabase

Supabase RLS Audit —
finde die Lecks, bevor es deine Nutzer tun.

In einer Supabase-App IST Row Level Security das Sicherheitsmodell — und in den meisten KI-gebauten Apps ist sie falsch konfiguriert oder ganz abgeschaltet. Wir auditieren jede Tabelle, Policy, jeden Bucket und jede Funktion so, wie ein Angreifer es tun würde, reparieren, was kaputt ist, und hinterlassen Tests, die beweisen, dass es dicht bleibt.

Audit buchen

Die Lage

Red Flags, die wir jede Woche finden

RLS auf neuen Tabellen deaktiviert

KI-Builder erstellen Tabellen schneller, als sie sie absichern. Eine ungeschützte Tabelle heißt: jede Zeile ist über die Auto-API lesbar.

Policies, die richtig aussehen — aber nicht sind

USING (true), fehlende WITH-CHECK-Klauseln, oder Policies auf User-Metadaten, die der Client selbst ändern kann.

Der service_role-Key im Client-Code

Der Key, der RLS komplett umgeht, ausgeliefert an den Browser. Game over — und häufiger, als du denkst.

Storage-Buckets stehen offen

Die Tabellen-Policies haben Aufmerksamkeit bekommen; die Buckets mit Rechnungen, Uploads und Exporten nicht.

Views und Funktionen umgehen RLS

SECURITY-DEFINER-Funktionen und Views ignorieren deine Tabellen-Policies stillschweigend — ein Lieblingsversteck für Lecks.

Keine Tests, also kein Beweis

Du hast letzte Woche eine Policy geändert und hoffst, dass nichts gebrochen ist. Hoffnung ist kein Sicherheitsmodell.

Was wir tun

Alles zwischen deinem Prototyp und Produktion.

Komplettes Policy-Review: jede Tabelle, View & Funktion

Storage-Bucket- & Edge-Function-Berechtigungen

Auth-Review: JWT-Claims, Rollen, Metadaten-Vertrauen

Anon-/service_role-Key-Exposure im gesamten Code

Angriffssimulation mit echten API-Calls pro Rolle

Neu geschriebene Policies mit sauberen WITH-CHECK-Constraints

Automatisierte RLS-Testsuite, damit es dicht bleibt

Schriftlicher Report: Fund → Schweregrad → Fix

So läuft es

Audit → Go-Live → SLA.

Audit

€1.500

Festpreis · Teil des Production-Readiness-Audits

Wir kartieren dein Berechtigungsmodell, lesen jede Policy und greifen deine API mit jeder Rolle an. Du bekommst einen Report über jedes Loch, nach Schweregrad bewertet.

Fixen & härten

Festpreis

aus dem Audit scoped · Audit wird angerechnet

Wir schreiben die Policies um dein echtes Produktmodell neu, sichern Storage und Funktionen, rotieren exponierte Keys — und beweisen es mit einem Re-Test.

Dicht halten

ab €290/Monat

SLA · optional, aber empfohlen

Jede Schema-Änderung kann ein Loch wieder öffnen. Im SLA läuft die RLS-Testsuite in der CI — und wir bleiben verantwortlich für das, was wir abgesichert haben.

Warum THE SWARM

Der Unterschied: Wer haftet.

Wir denken wie ein Angreifer

Wir lesen Policies nicht nur und nicken — wir rufen deine API mit jeder Rolle auf und versuchen, Daten zu ziehen, die uns nichts angehen. Jeder Fund kommt mit funktionierendem Beweis.

Fixes statt nur Findings

Ein PDF voller Probleme schützt niemanden. Wir schreiben die Policies neu, migrieren sicher mit bestehenden Daten und testen nach.

Beweis, dass es dicht bleibt

Du bekommst eine automatisierte RLS-Testsuite in der CI — die nächste Schema-Änderung kann das Leck von gestern nicht mehr still wieder öffnen.

Fragen

Supabase RLS Audit — Antworten.

Lesezugriff aufs Repository und eine Member-Einladung ins Supabase-Projekt reichen. Wir testen wo möglich gegen Staging oder eine Branch-Datenbank; alles Richtung Produktion ist read-only und mit dir abgestimmt.

Unser häufigster Fall. KI-Tools generieren funktionierende Queries, aber selten korrekte Policies — die App wirkt in Ordnung, weil der Happy Path funktioniert, während die API viel mehr erlaubt, als die UI zeigt.

Einen schriftlichen Report (Fund, Schweregrad, verständliche Auswirkung, Fix), korrigierte Policies, eine automatisierte Testsuite und einen Re-Test, der beweist, dass die Löcher zu sind.

Ja — genau darum geht es. Das Audit kostet €1.500 fix und wird voll auf die Fix-Arbeit angerechnet, die wir nach dem Audit zum Festpreis anbieten.

Guter Anfang. Er markiert Tabellen ohne RLS — aber er kann nicht beurteilen, ob deine Policies zum echten Berechtigungsmodell deines Produkts passen: wer welche Zeilen sehen darf und warum. Dafür muss ein Mensch Produkt und Schema zusammen lesen.