supabase/supabase

Was macht supabase?

Kernprinzipien

1. Supabase ändert sich häufig — vor der Implementierung Änderungsprotokoll und aktuelle Dokumentation prüfen. Verlassen Sie sich nicht auf Trainingsdaten für Supabase-Funktionen. Funktionssignaturen, config.toml-Einstellungen und API-Konventionen ändern sich zwischen Versionen.

Rufen Sie zuerst https://supabase.com/changelog.md (eine kurze Zusammenfassung – kein schwerer Abruf) ab, scannen Sie nach breaking-change-Tags, die für Ihre Aufgabe relevant sind, und folgen Sie der verlinkten Seite für alle zutreffenden. Schlagen Sie dann das relevante Thema mit den untenstehenden Methoden für den Dokumentationszugriff nach.

2. Überprüfen Sie Ihre Arbeit. Führen Sie nach der Implementierung einer Korrektur eine Testabfrage aus, um die Änderung zu bestätigen. Eine Korrektur ohne Überprüfung ist unvollständig.

3. Erholen Sie sich von Fehlern, wiederholen Sie keine Endlosschleifen. Wenn ein Ansatz nach 2-3 Versuchen fehlschlägt, stoppen Sie und überdenken Sie ihn. Versuchen Sie eine andere Methode, überprüfen Sie die Dokumentation, untersuchen Sie den Fehler sorgfältiger und sehen Sie sich die relevanten Protokolle an, falls verfügbar. Supabase-Probleme werden nicht immer durch Wiederholen desselben Befehls gelöst, und die Antwort liegt nicht immer in den Protokollen, aber es lohnt sich oft, die Protokolle zu überprüfen, bevor Sie fortfahren.

4. Tabellen für die Daten-API verfügbar machen: Abhängig von den Daten-API-Einstellungen des Benutzers werden neu erstellte Tabellen möglicherweise nicht automatisch über die Daten- (REST) API verfügbar gemacht. Wenn dies der Fall ist, muss den Rollen anon und authenticated explizit Zugriff gewährt werden.

Beachten Sie, dass dies getrennt von RLS ist, das steuert, welche Zeilen sichtbar sind, sobald eine Tabelle zugänglich ist, und nicht, ob die Tabelle überhaupt zugänglich ist.

Wenn ein Benutzer meldet, dass eine per SQL erstellte Tabelle unerwartet nicht zugänglich ist, überprüfen Sie seine Daten-API-Einstellungen und ob den Rollen Zugriff über explizites GRANT SQL gewährt wurde. Wenn Sie öffentlichen (anon/authenticated) Zugriff gewähren, aktivieren Sie auch immer RLS. Siehe Tabelle für die Daten-API verfügbar machen für den vollständigen Einrichtungsworkflow.

5. RLS in exponierten Schemas. Aktivieren Sie RLS auf jeder Tabelle in jedem exponierten Schema, einschließlich public standardmäßig. Dies ist in Supabase kritisch, da Tabellen in exponierten Schemas über die Daten-API erreichbar sein können, wenn die Rollen anon/authenticated Zugriff haben (siehe Tabelle für die Daten-API verfügbar machen). Für private Schemas bevorzugen Sie RLS als mehrschichtige Verteidigung. Erstellen Sie nach dem Aktivieren von RLS Richtlinien, die zum tatsächlichen Zugriffsmodell passen, anstatt standardmäßig für jede Tabelle dasselbe auth.uid()-Muster zu verwenden.

6. Sicherheits-Checkliste. Wenn Sie an einer Supabase-Aufgabe arbeiten, die Auth, RLS, Views, Storage oder Benutzerdaten betrifft, gehen Sie diese Checkliste durch. Dies sind Supabase-spezifische Sicherheitsfallen, die stillschweigend Schwachstellen schaffen:

• Auth- und Sitzungssicherheit

  • Verwenden Sie user_metadata-Claims niemals für JWT-basierte Autorisierungsentscheidungen. In Supabase ist raw_user_meta_data vom Benutzer bearbeitbar und kann in auth.jwt() erscheinen, daher ist es für RLS-Richtlinien oder andere Autorisierungslogik unsicher. Speichern Sie Autorisierungsdaten stattdessen in raw_app_meta_data / app_metadata.
  • Das Löschen eines Benutzers macht vorhandene Zugriffstoken nicht ungültig. Melden Sie sich zuerst ab oder widerrufen Sie Sitzungen, halten Sie die JWT-Ablaufzeit für sensible Apps kurz, und validieren Sie für strenge Garantien bei sensiblen Operationen session_id gegen auth.sessions.
  • Wenn Sie app_metadata oder auth.jwt() zur Autorisierung verwenden, denken Sie daran, dass JWT-Ansprüche nicht immer aktuell sind, bis das Token des Benutzers aktualisiert wird.

• API-Schlüssel- und Client-Exposition

  • Setzen Sie den service_role oder geheimen Schlüssel niemals in öffentlichen Clients ein. Bevorzugen Sie veröffentlichbare Schlüssel für Frontend-Code. Legacy-anon-Schlüssel sind nur für die Kompatibilität. In Next.js wird jede NEXT_PUBLIC_-Umgebungsvariable an den Browser gesendet.

• RLS, Views und privilegierter Datenbankcode

  • Views umgehen standardmäßig RLS. Verwenden Sie in Postgres 15 und höher CREATE VIEW ... WITH (security_invoker = true). Schützen Sie in älteren Versionen von Postgres Ihre Views, indem Sie den Zugriff für die Rollen anon und authenticated entziehen, oder indem Sie sie in einem nicht exponierten Schema ablegen.
  • UPDATE erfordert eine SELECT-Richtlinie. In Postgres RLS muss ein UPDATE zuerst die Zeile SELECTEN. Ohne eine SELECT-Richtlinie geben Updates stillschweigend 0 Zeilen zurück – kein Fehler, nur keine Änderung.
  • auth.role() ist veraltet – verwenden Sie stattdessen die TO-Klausel. Supabase hat auth.role() zugunsten der direkten Angabe der Zielrolle in der Richtlinie mit TO authenticated oder TO anon abgelehnt. Über die Veraltung hinaus bricht auth.role() = 'authenticated'' stillschweigend, wenn anonyme Anmeldungen aktiviert sind, weil anonyme Benutzer die Postgres-Rolle authenticated` tragen und die Prüfung unabhängig davon bestehen, ob der Benutzer wirklich angemeldet ist.

    -- Veraltet (nicht verwenden)
    create policy "example" on table_name for select
    using ( auth.role() = 'authenticated' );
    

  • TO authenticated allein ist Authentifizierung ohne Autorisierung (BOLA / IDOR). Die Verwendung von TO authenticated prüft nur die Rolle – sie schränkt nicht ein, auf welche Zeilen ein Benutzer zugreifen kann. Das korrekte Muster kombiniert TO authenticated mit einem Besitzprädikat in USING:

    create policy "example" on table_name for select
    to authenticated
    using ( (select auth.uid()) = user_id );
    

  • UPDATE-Richtlinien erfordern sowohl USING als auch WITH CHECK. Ohne WITH CHECK kann ein Benutzer die user_id einer Zeile einem anderen Benutzer zuweisen:

    create policy "example" on table_name for update
    to authenticated
    using ( (select auth.uid()) = user_id )
    with check ( (select auth.uid()) = user_id );
    

  • SECURITY DEFINER-Funktionen umgehen RLS. Eine SECURITY DEFINER-Funktion wird mit den Berechtigungen ihres Erstellers ausgeführt – typischerweise einer Rolle mit bypassrls (z.B. postgres). Fügen Sie niemals SECURITY DEFINER hinzu, um einen Berechtigungsfehler zu beheben; es entfernt stillschweigend die Zugriffskontrolle, ohne die zugrunde liegende Ursache zu beheben. Bevorzugen Sie SECURITY INVOKER.
  • SECURITY DEFINER-Funktionen in public sind von allen Rollen aufrufbar. Postgres gewährt standardmäßig für jede neue Funktion EXECUTE an PUBLIC, daher ist jede SECURITY DEFINER-Funktion in public ein öffentlicher API-Endpunkt, der von anon und authenticated aufrufbar ist (die von PUBLIC erben), ohne zusätzliche Berechtigung. Wenn SECURITY DEFINER wirklich benötigt wird (z.B. Umgehung von RLS in einer internen Nachschlagetabelle), halten Sie die Funktion in einem nicht exponierten Schema, fügen Sie immer eine auth.uid()-Prüfung im Funktionsrumpf ein und führen Sie supabase db advisors nach Änderungen aus.

• Speicherzugriffskontrolle

  • Storage-Upsert erfordert INSERT + SELECT + UPDATE. Nur INSERT zu gewähren, ermöglicht neue Uploads, aber das Ersetzen von Dateien (Upsert) schlägt stillschweigend fehl. Sie benötigen alle drei.

• Abhängigkeits- und Lieferkettensicherheit

  • Pin-Paketversionen und committen Sie Sperrdateien immer, wenn Sie Supabase-Pakete installieren (supabase-js, @supabase/ssr, supabase-py usw.). Siehe den npm-Sicherheitsleitfaden für die vollständige Checkliste.

Wenn ein Sicherheitsbedenken nicht oben abgedeckt ist, rufen Sie den Supabase-Produktsicherheitsindex ab: https://supabase.com/docs/guides/security/product-security.md

Supabase CL