Supabase RLS uitgelegd: kunnen uw gebruikers elkaars gegevens zien?

Wat is Row Level Security (RLS)?

Supabase is een kant-en-klare database met inlogsysteem, die veel AI-tools zoals Lovable en Bolt gebruiken. Supabase RLS (Row Level Security) is de beveiliging die bepaalt wie welke gegevens in die database mag zien. Bij een gewone website praat alleen de server met de database. Bij Supabase is dat anders. De app in de browser vraagt gegevens met een publieke sleutel rechtstreeks op bij de database. Die sleutel staat in de code van uw app en kan iedere bezoeker vinden. Dat is zo bedoeld.

Wat bepaalt dan wie wat mag zien? Dat doet Row Level Security: een regel per tabel. Die zegt welke rijen een gebruiker mag lezen, toevoegen, wijzigen of verwijderen. Vergelijk het met een archiefkast. De publieke sleutel opent de kamer; RLS bepaalt welke lades u open krijgt. Zonder RLS staan alle lades open.

Supabase zegt het zelf duidelijk. Een tabel zonder RLS is leesbaar en schrijfbaar voor iedereen met toegang tot de database. Zet RLS daarom aan op elke tabel die via de API bereikbaar is.

Waarom lekten zoveel Lovable- en Bolt-apps?

In maart 2025 vond onderzoeker Matt Palmer een groot probleem in apps die met Lovable waren gebouwd. Een scan vond 303 kwetsbare punten in 170 van de 1.645 onderzochte apps. Door ontbrekende of verkeerde RLS-regels waren gegevens op te vragen zonder in te loggen. Het ging om namen, e-mailadressen en telefoonnummers, maar ook betaalstatus en API-sleutels. Het lek kreeg de code CVE-2025-48757 en de ernstscore 9,3 van 10.

Een latere scan uit 2026 vond kritieke lekken bij 7,1% van de onderzochte Lovable-apps en 7,3% van de Bolt-apps. De oorzaak was telkens dezelfde: RLS stond uit op tabellen met echte gebruikersgegevens.

Waarom gebeurt dit? Zodra RLS aan staat zonder goede regel, geeft de database niets meer terug en lijkt de app kapot. De snelste manier om de preview weer te laten werken, is RLS uitzetten of een regel toevoegen die alles toestaat. Een AI-tool die vooral een werkende app wil opleveren, kiest dan soms die weg.

RLS aan is niet hetzelfde als RLS goed

Dit is de valkuil. Een tabel kan RLS aan hebben en toch openstaan. Een regel met using (true) betekent: iedereen mag alles zien. Volgens Supabase geeft zo’n regel elke bezoeker zonder inlog leestoegang tot alle rijen. Gebruik dat alleen voor gegevens die echt openbaar mogen zijn, zoals een productcatalogus.

Lovable had een eigen beveiligingscontrole die keek óf er een regel bestond. Of die regel ook echt beschermde, controleerde hij niet. Een regel die alles toestond, zag er voor de controle hetzelfde uit als een goede. Daardoor voelden eigenaren zich veilig terwijl hun gegevens openlagen.

Een goede regel kijkt naar de ingelogde gebruiker. Een voorbeeld voor uw bouwer, voor een tabel met bestellingen: create policy "Eigen bestellingen lezen" on bestellingen for select to authenticated using ((select auth.uid()) = user_id). Zo ziet elke klant alleen zijn eigen bestellingen.

Let ook op views (opgeslagen zoekopdrachten). Supabase waarschuwt dat views de RLS-regels standaard overslaan, omdat ze met de rechten van de beheerder worden gemaakt.

Hoe controleert u of Supabase RLS echt werkt?

Doe dit alleen op uw eigen app. Stap 1: open in Supabase de Table Editor. Kijk bij elke tabel met klant- of bedrijfsgegevens of RLS aan staat.

Stap 2: bekijk per tabel de regels (policies). Staat er using (true) bij een tabel met persoonsgegevens, dan is dat een rode vlag. Een goede regel noemt auth.uid(). Er is een aparte regel voor lezen, toevoegen, wijzigen en verwijderen.

Stap 3, de belangrijkste: test het gedrag. Maak twee testaccounts, A en B. Leg met A een bestelling of profiel aan. Log in als B en probeer die gegevens te openen, bijvoorbeeld door een nummer in de adresbalk te veranderen. Log daarna helemaal uit en probeer het opnieuw. Ziet u iets van A, dan werkt RLS niet.

Stap 4: vergeet de bestandsopslag niet. Opslag voor bestanden heeft eigen regels, los van de database. Bij de Tea-app lekten zo ongeveer 72.000 foto’s, waaronder identiteitsbewijzen.

Wat u vraagt aan uw bouwer of AI-tool

Lovable raadt deze prompt aan: "Review RLS policies to ensure users can only access their own data and shared data is properly protected". Supabase heeft een officiële prompt die AI-tools dwingt RLS-regels goed te schrijven. Met auth.uid() en een aparte regel per handeling. En met een controle of RLS al aan staat.

Vraag uw bouwer ook om een lijst van alle tabellen. Per tabel staat erin of RLS aan staat en wie wat mag. Een bouwer die dat niet kan maken, heeft het waarschijnlijk niet gecontroleerd.

Wanneer laat u RLS testen?

Een scan vindt snel of tabellen zonder inlog op te vragen zijn. De Scan (vanaf € 295 excl. btw) is daarvoor een goede eerste stap. Dat is een scan die wij met de hand nalopen, geen pentest.

Of gebruiker B bij gegevens van gebruiker A kan, onderzoeken we met afgesproken testaccounts. Dat hoort bij de Inbraaktest Totaal (vanaf € 4.950), inclusief gebruikersrollen en API’s binnen de afgesproken scope. De Inbraaktest test uitsluitend van buitenaf, zonder inlog. Hertest inbegrepen. Wij testen alleen na schriftelijke toestemming van de eigenaar van het systeem.