Supabase Row Level Security (RLS): sichere deine Tabellen ab

Führe das im Supabase SQL Editor aus, um jede Tabelle im exponierten public-Schema aufzulisten, bei der RLS noch ausgeschaltet ist. Der Security Advisor im Dashboard meldet dasselbe Problem als „RLS disabled in public“.

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;

Schalte RLS für jede Tabelle ein und füge dann pro Operation eine Policy hinzu. Beschränke Policies auf die Rolle authenticated und vergleiche die Owner-Spalte der Zeile mit auth.uid(). Inserts und Updates brauchen with check, damit Nutzer keine Zeilen schreiben können, die jemand anderem gehören.

alter table public.profiles enable row level security;

create policy "Users read own profile"
  on public.profiles for select
  to authenticated
  using ((select auth.uid()) = user_id);

create policy "Users update own profile"
  on public.profiles for update
  to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

Ersetze Platzhalter-Policies wie using (true) durch echte Bedingungen. Stütze die Autorisierung nicht auf user_metadata — das können Nutzer selbst bearbeiten; verwende stattdessen app_metadata oder eine Rollentabelle. Views umgehen RLS, sofern sie nicht mit security_invoker = true erstellt werden, und Storage-Buckets brauchen eigene Policies auf storage.objects.

Frage deine API genau so ab, wie es ein Angreifer tun würde: nur mit dem öffentlichen Key und ohne Nutzer-Session. Liefert das Zeilen zurück, die nicht öffentlich sein sollen, sind deine Policies zu offen.

curl "https://<project>.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: <anon-key>" \
  -H "Authorization: Bearer <anon-key>"

Verwende den service_role-Key (sb_secret_) nur in Server-Code wie API-Routen oder Edge Functions, niemals hinter einem NEXT_PUBLIC_- oder VITE_-Präfix. Wurde er jemals an den Browser ausgeliefert, rotiere ihn im Dashboard.