Checklist RLS w Supabase zanim pójdziesz live

Co sprawdzić w RLS Supabase zanim pójdziesz live?

Zanim pójdziesz live z Supabase, każda tabela z danymi użytkowników lub treścią edytowalną powinna mieć włączone Row Level Security i polityki, które domyślnie odmawiają dostępu. Klucz anonimowy w przeglądarce jest publiczny — zakładaj, że ktoś użyje go poza Twoim UI i wywoła API bezpośrednio. Checklist startowy obejmuje RLS na wszystkich tabelach biznesowych, osobne polityki SELECT, INSERT, UPDATE i DELETE oraz brak szeroko otwartego using true na zapisie. Kolumny wrażliwe nie mogą być dostępne dla roli anon; service role key zostaje wyłącznie na serwerze w Route Handlers lub Server Actions, nigdy w bundle klienta. Bucket’y Storage potrzebują własnych reguł, a publiczny odczyt tylko dla świadomie publicznych assetów. Na koniec wykonaj test negatywny: próba odczytu cudzego wiersza i nieopublikowanego posta musi kończyć się pustką lub błędem, nie danymi. Bez tego „działa lokalnie” nic nie znaczy na produkcji.

Jak bezpiecznie obsłużyć formularz kontaktowy i zapis z klienta?

Formularz kontaktowy nie powinien insertować się do bazy bezpośrednio z przeglądarki przy szerokiej polityce INSERT dla roli anon. Bezpieczniejszy wzorzec to POST do własnego route handlera, walidacja schematem, honeypot albo rate limit, a dopiero potem zapis przez klienta service role albo wysyłka maila bez eksponowania sekretów. Jeśli zostawiasz INSERT dla anon, ogranicz go do konkretnych kolumn, bez możliwości ustawiania flagi published, ról administracyjnych czy cudzego user id, i dodaj limity po stronie bazy lub edge. Nigdy nie zwracaj service role ani pełnych logów błędu SQL do odpowiedzi HTTP klienta. Po zapisie rewaliduj tylko to, co potrzeba, i nie loguj treści wiadomości w publicznych narzędziach analitycznych. Ten sam układ stosuj do newslettera, uploadów i wszystkich ścieżek zapisu otwartych na internet. Traktuj każdy publiczny write path jak potencjalny wektor spamu, scrape’u i abuse — bo dokładnie tak go zobaczy bot.

Jak przetestować polityki RLS przed launch’em?

Polityki RLS testuje się scenariuszami, a nie samym wrażeniem że „w UI po zalogowaniu działa”. Przygotuj co najmniej użytkownika anonimowego, zwykłego zalogowanego i admina oraz rekordy opublikowane i draftowe. Sprawdź próbę SELECT cudzych wiadomości kontaktowych i UPDATE cudzego profilu — obie powinny być zablokowane. Uruchom te case’y z poziomu SQL na rolach anon i authenticated albo automatów ustawiających testowy JWT. Zweryfikuj Storage: czy da się wypisać listę prywatnych obiektów i czy upload przyjmuje tylko dozwolone typy MIME oraz limity rozmiaru. Po każdej zmianie polityki powtórz suite, bo regresje RLS są częste przy szybkiej poprawce na produkcji. Dopiero gdy testy negatywne przechodzą, otwierasz ruch; w przeciwnym razie launch to loteria z danymi klientów. Wpisz te scenariusze negatywne do CI albo do checklisty release, żeby nie polegać wyłącznie na pamięci jednego developera w całym zespole produktowym.