Row Level Security

Klucz anon jest publiczny, więc to polityki RLS decydują, kto może czytać i zmieniać dane. Zasada: każda tabela w schemacie public musi mieć włączone RLS.

Włączenie RLS

alter table public.todos enable row level security;

Bez polityk tabela z włączonym RLS jest niedostępna dla anon i authenticated — to bezpieczny stan domyślny.

Typowe polityki

-- każdy może czytać opublikowane wpisy
create policy "Publiczny odczyt"
  on posts for select
  using (published = true);

-- autor zarządza swoimi wpisami
create policy "Autor edytuje"
  on posts for update to authenticated
  using (auth.uid() = author_id)
  with check (auth.uid() = author_id);

-- członkowie zespołu widzą dane zespołu
create policy "Członkowie zespołu"
  on projects for select to authenticated
  using (
    team_id in (select team_id from team_members where user_id = auth.uid())
  );

Wydajność

• Opakuj auth.uid() w podzapytanie: using ((select auth.uid()) = user_id) — Postgres policzy je raz zamiast dla każdego wiersza.
• Dodaj indeksy na kolumnach używanych w politykach (np. user_id).
• Określaj role w politykach (to authenticated), by ograniczyć ich ewaluację.

Klucz service_role

Klucz service_role omija RLS. Używaj go wyłącznie na serwerze (backend, Edge Functions, zadania cron). Jeśli wycieknie — natychmiast wygeneruj nowy sekret JWT w ustawieniach projektu.

Checklist bezpieczeństwa

• RLS włączone na wszystkich tabelach w public.
• Brak klucza service_role w kodzie frontendu i w repozytorium.
• Silne hasło do bazy, rotowane po odejściu członka zespołu.
• Ograniczone Redirect URLs w ustawieniach Auth.
• Włączone 2FA na koncie HostBase.