Integration Testing mit Supabase: RLS-Policies sicher testen
Unit-Tests reichen nicht. Erfahre, wie du deine Datenbank-Abfragen und Row Level Security (RLS) in Supabase mit echten Integration-Tests absicherst.
Wir alle kennen das gute Gefühl, wenn die Unit-Tests für unsere JavaScript-Funktionen grün sind. Aber was passiert, wenn die App mit der Datenbank spricht? In einer Supabase-App liegt ein Großteil der Sicherheitslogik nicht im Code, sondern direkt in der Datenbank: in den Row Level Security (RLS) Policies.
Wenn du nur dein Frontend testest, übersiehst du das kritischste Glied der Kette. Integration-Tests sind der einzige Weg, um sicherzustellen, dass Nutzer A niemals die privaten Daten von Nutzer B sehen kann. In diesem Guide zeige ich dir, wie du eine robuste Test-Strategie für deine Supabase-Backend-Logik aufbaust.
Warum RLS-Tests unverzichtbar sind
Row Level Security ist fantastisch, aber fehleranfällig. Eine Policy wie auth.uid() = user_id klingt einfach. Aber was ist mit komplexeren Szenarien? Team-Berechtigungen, öffentliche Profile oder Admin-Rollen? Ein kleiner Tippfehler in deiner SQL-Policy kann deine gesamte Anwendung für Datenlecks öffnen.
Meine Meinung: Ein Bug im Frontend ist ärgerlich, ein Bug in der RLS-Policy ist ein Desaster. Wer professionell mit Supabase arbeitet und keine automatisierten Tests für seine Policies hat, handelt fahrlässig.
Die lokale Test-Umgebung: Supabase CLI
Du solltest niemals gegen deine Live-Datenbank oder dein Staging-Projekt testen. Das ist langsam und unzuverlässig. Die Lösung ist die Supabase CLI.
Mit supabase init und supabase start holst du dir die komplette Supabase-Umgebung als Docker-Container auf deinen Rechner. Deine Tests laufen gegen eine frische, lokale Instanz, die du nach jedem Test-Lauf zurücksetzen kannst.
Testing mit Vitest und dem Supabase Client
Der einfachste Weg für Webentwickler ist die Nutzung von Vitest. Wir erstellen zwei verschiedene Supabase-Clients: Einen "Service Role Client" (Admin), um Testdaten anzulegen, und einen "User Client", der die Berechtigungen eines normalen Nutzers simuliert.
Beispiel: Test eines Daten-Zugriffs
import { describe, it, expect, beforeAll } from 'vitest'
import { createClient } from '@supabase/supabase-js'
const supabaseAdmin = createClient(URL, SERVICE_ROLE_KEY)
const supabaseUser = createClient(URL, ANON_KEY)
describe('RLS: Posts Tabelle', () => {
it('sollte einem Nutzer verbieten, fremde private Posts zu lesen', async () => {
// 1. Admin legt einen privaten Post für Nutzer A an
await supabaseAdmin.from('posts').insert({
title: 'Geheim',
user_id: 'nutzer-a-uuid',
is_public: false
})
// 2. Nutzer B versucht den Post zu lesen
const { data } = await supabaseUser
.from('posts')
.select('*')
.eq('title', 'Geheim')
// 3. Erwartung: Das Ergebnis ist leer (RLS blockt)
expect(data?.length).toBe(0)
})
})
Dieser Test simuliert einen echten Angriff: Ein Nutzer versucht, via API auf Daten zuzugreifen, die ihm nicht gehören. Wenn deine RLS-Policy korrekt ist, liefert Supabase einfach ein leeres Array zurück.
Fortgeschrittene Tests mit pgTAP
Wenn du SQL-Profi bist (oder es werden willst), solltest du dir pgTAP anschauen. Das ist ein Test-Framework, das direkt innerhalb von PostgreSQL läuft. Es erlaubt dir, Tabellen-Strukturen, Indizes und eben auch Policies auf SQL-Ebene zu validieren.
Supabase unterstützt pgTAP nativ in der CLI. Du schreibst deine Tests als .sql Dateien und führst sie mit supabase test db aus. Das ist oft schneller und präziser als der Umweg über JavaScript.
CI/CD: Sicherheit automatisieren
Ein Test ist nur nützlich, wenn er regelmäßig läuft. Integriere deine Supabase-Tests in deine GitHub Actions. Bei jedem Pull Request wird eine lokale Supabase-Instanz gestartet, die Migrationen werden eingespielt und die RLS-Tests laufen durch. Erst wenn alles grün ist, darf der Code gemergt werden.
Fazit: Schlafe ruhiger mit Integration-Tests
Integration-Testing mit Supabase fühlt sich am Anfang nach viel Aufwand an. Du musst Docker verwalten, Testdaten generieren und dich mit SQL-Sicherheitskonzepten auseinandersetzen. Aber der Lohn ist unbezahlbar: Das Wissen, dass deine Daten geschützt sind, egal was im Frontend passiert.
Verlasse dich nicht auf manuelle Klick-Tests im Dashboard. Automatisiere deine Backend-Sicherheit und baue Anwendungen, denen deine Nutzer blind vertrauen können.
Verwandte Artikel für Testing-Profis:
FAQ zu diesem Artikel
d6benjamin
Willkommen auf d6b