RLS (Row Level Security)

RLS to reguły zapisane w samej bazie danych, które przy każdym pytaniu o dane sprawdzają: „czy ta osoba może zobaczyć ten wiersz?”. Działają nawet wtedy, gdy Twoja aplikacja się pomyli. Dlatego są ostatnią linią obrony danych Twoich klientów.

Co to jest

Wyobraź sobie biuro z wielką szafą. Każdy klient ma w niej własną szufladę. Logowanie to klucz do pokoju z szafą. RLS to osobny zamek na każdej szufladzie: kluczem klienta A otworzysz tylko szufladę A. Szuflada B stoi tuż obok, ale zostaje zamknięta.

Skrót pochodzi od angielskiego Row Level Security, czyli „zabezpieczenie na poziomie wierszy”. Wiersz to jeden zapis w tabeli: jedno zamówienie, jedna faktura, jeden profil. Reguła brzmi w zwykłych słowach tak: „zamówienie może zobaczyć tylko osoba, która je złożyła”. Baza dopisuje ten warunek do każdego pytania, bez względu na to, skąd przyszło.

Dlaczego to takie ważne przy Supabase? Przeglądarka Twojego klienta rozmawia z bazą bezpośrednio. Przedstawia się kluczem publicznym, który każdy może podejrzeć w kodzie strony. Ten klucz to jak numer telefonu do biura: zna go każdy, więc niczego nie chroni. Chronią dopiero zamki na szufladach, czyli reguły RLS.

RLS spotkasz też w Power BI czy SQL Server — idea jest ta sama (filtr na wierszach), ale tu opisujemy RLS w bazie PostgreSQL, na której działa Supabase.

Co się psuje w prawdziwej aplikacji

Najgorsze jest to, że brak RLS niczego widocznie nie psuje. Aplikacja działa, każdy klient widzi na ekranie swoje dane, testy przechodzą. To jak szafa bez zamków, która z daleka wygląda porządnie. Problem zauważa dopiero ktoś, kto zamiast klikać w ekran, zapyta bazę wprost.

W 2025 roku opisano lukę w aplikacjach generowanych na platformie Lovable: niewystarczające reguły RLS pozwalały obcym odczytywać i zapisywać dane w tabelach (CVE-2025-48757 w bazie NVD). Dostawca kwestionuje to zgłoszenie, wskazując, że za ochronę danych odpowiada twórca każdej aplikacji. I właśnie o to chodzi: agent zbudował działającą aplikację, ale zamków na szufladach nie założył — a twórcy nie wiedzieli, że trzeba.

Najczęstsze błędy wyglądają tak:

• szuflady bez zamków — tabela bez włączonego RLS jest otwarta dla każdego z kluczem publicznym;
• jeden klucz do wszystkich szuflad — reguła „dla zalogowanych” zamiast „dla właściciela”, więc każdy klient widzi dane wszystkich klientów;
• zamek tylko na oglądanie — reguła pilnuje odczytu, ale nie zapisu, więc klient może zmienić cudzy wiersz albo sam sobie nadać płatny plan;
• tylne drzwi — tak zwany widok (gotowe zestawienie z kilku tabel) potrafi omijać reguły, jeśli nie oznaczy się go ustawieniem security_invoker.

Jak to sprawdzić u siebie

Rób to tylko na własnym projekcie i na własnych kontach testowych.

1. Czy każda szuflada ma zamek. W panelu Supabase tabela bez zabezpieczenia ma ostrzeżenie „RLS disabled”. Zakładka Security Advisor wypisuje problemy z regułami. Każde ostrzeżenie traktuj jak usterkę do naprawy, nie jak radę.

2. Test obcego. Wyloguj się i spróbuj odczytać każdą tabelę samym kluczem publicznym. Agent przygotuje Ci do tego krótki skrypt. Dobry wynik: zero wierszy z danymi klientów.

3. Test dwóch kont. Załóż konto A i konto B. Jako A utwórz zapis. Zalogowany jako B spróbuj go odczytać, zmienić i usunąć. Nie tylko przez ekran, ale też bezpośrednim zapytaniem. W bazie liczba wierszy przed i po ma być taka sama.

1. Test awansu. Jako zwykłe konto spróbuj zmienić we własnym wierszu pole typu „plan” albo „rola”. Ma się nie udać.
2. Klucz kierownika. Supabase ma też klucz serwisowy (service_role), który otwiera wszystkie szuflady naraz. Sprawdź, że nie trafia do przeglądarki ani do ustawień z przedrostkiem NEXT_PUBLIC_.

Dokumentacja: Supabase — Row Level Security.

W code2saas: brama B1

RLS to serce bramy B1 „Bezpieczeństwo”. Nie wystarczy powiedzieć „mam RLS”. Punkt zaliczasz dopiero dowodem: wynikiem pokazującym zero tabel bez zabezpieczenia, testem obcego z zerem wierszy i testem dwóch kont z liczbami przed i po. Bez dowodu wynik to „NIE WIEM”, nigdy „PASS”. Jeśli budujesz aplikację z kontami i chcesz przejść tę drogę z prowadzeniem, wyślij zgłoszenie do Buildera.

Najczęstsze pytania

Mam logowanie. Czy to nie wystarczy?

Nie. Logowanie odpowiada na pytanie „kim jesteś?”. RLS odpowiada na pytanie „co wolno Ci zobaczyć?”. Bez tego drugiego zalogowany klient może zajrzeć do cudzych szuflad.

Czy AI napisze mi reguły RLS?

Napisze, często dobrze. Ale agent potrafi pominąć jedną tabelę albo napisać regułę zbyt szeroką. Dlatego reguły sprawdzasz testem dwóch kont, a nie czytaniem kodu.

Czy włączenie RLS wystarczy, żeby było bezpiecznie?

Nie, i to zaskakuje wielu początkujących. Dokumentacja Supabase każe włączyć RLS na każdej tabeli dostępnej z aplikacji, a automatyczne włączanie dla nowych tabel to osobne ustawienie, które trzeba sobie dodać. Tabele zakładane poleceniami w bazie, migracjami albo przez agenta sprawdzaj więc zawsze sam. Pamiętaj też, że włączone RLS bez żadnej reguły zamyka wszystko na głucho. Reguły trzeba napisać pod swoje dane.