Waarom is Row-Level Security belangrijker dan normale toegangscontrole op applicatieniveau?

Met normale applicatiecontrole hangt databeveiliging af van je code die altijd correct is. Een onbedoelde query zonder filter, een bug in je Xano-logica of een onjuist geconfigureerde WeWeb-binding kan verkeerde data blootstellen. RLS dwingt toegangscontrole af op databaseniveau ongeacht wat je applicatiecode doet — het is verdediging in de diepte en de sterkst mogelijke technische garantie.

Hoe test je of RLS-beleidsregels daadwerkelijk correct werken?

Gebruik Supabase's tabeleditor met een anon-sleutelcontext en probeer rijen op te halen die bij een andere tenant horen. Je kunt ook integratietests schrijven die inloggen als gebruiker A en verifiëren dat data van gebruiker B's workspace nooit wordt geretourneerd. Supabase Policy Editor heeft ook een ingebouwde testfunctie. Test altijd met representatief datavolume — 10.000+ rijen — om prestatieproblemen in N+1-situaties te detecteren.

Hoe bescherm je gevoelige kolomdata (bijv. salarissen) met RLS?

Naast rij-niveau-beleidsregels kun je Supabase Views maken die gevoelige kolommen uitsluiten en gebruikers toegang geven tot de view in plaats van de basistabel. Gecombineerd met RLS op de view worden zowel welke rijen als welke kolommen een gebruiker ziet gefilterd. Voor Nederlandse HR-systemen waar salarisdata alleen zichtbaar moet zijn voor de HR-afdeling is dit het standaardpatroon.

Kun je Supabase RLS gebruiken om te voldoen aan de AVG's vereisten voor datatoegangscontrole?

Ja. RLS is een sterk privacy-by-design-argument voor de AVG. Je kunt aan klanten en hun Functionarissen Gegevensbescherming aantonen dat data-isolatie plaatsvindt op databaseniveau zonder te vertrouwen op applicatiecode. Bij een eventuele AVG-handhavingsprocedure in Nederland is technische documentatie van RLS-beleidsregels concreet bewijs dat je passende beveiligingsmaatregelen hebt genomen conform AVG-artikel 32.

Supabase Row Level Security: Praktische gids voor SaaS

Waarom RLS belangrijk is voor SaaS

Zonder RLS is je API de enige barrière tussen een gebruiker en elke rij in je database. Een onbedoelde "haal alles op"-query en je hebt een datalek.

Met RLS dwingt PostgreSQL toegangsregels af bij het uitvoeren van query's. Ongeacht wat je API stuurt, retourneert de database alleen rijen die de geverifieerde gebruiker mag zien. Dit is verdediging in de diepte — je API en database dwingen toegangscontrole onafhankelijk van elkaar af.

Vanuit een AVG-perspectief is dit goud: je kunt aan je klanten (en hun Functionarissen Gegevensbescherming) aantonen dat data-isolatie op databaseniveau wordt afgedwongen — de sterkste mogelijke technische garantie. Bij een eventuele AVG-handhavingsprocedure is dit sterk bewijs van privacy-by-design.

RLS activeren

Activeer RLS op elke gebruikersgerichte tabel. Tabellen zonder RLS-beleidsregels zijn standaard wijd open (als ze worden benaderd via de service-rolsleutel) of volledig ontoegankelijk (als ze worden benaderd via de anon-sleutel zonder beleidsregels).

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

Wanneer geactiveerd worden standaard geen rijen geretourneerd totdat je beleidsregels maakt. Dit is de correcte beveiligingspositie.

Maak een checklist voor je team: elke nieuwe tabel krijgt RLS geactiveerd voordat deze wordt verbonden met de frontend. We raden aan dit toe te voegen als stap in je PR-sjabloon of deploy-checklist.

Het basispatroon voor gebruikerseigendom

Het meest voorkomende patroon — gebruikers kunnen alleen hun eigen rijen zien en wijzigen: CREATE POLICY "Users can view own rows" ON projects FOR SELECT USING (auth.uid() = user_id);

CREATE POLICY "Users can insert own rows" ON projects FOR INSERT WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Users can update own rows" ON projects FOR UPDATE USING (auth.uid() = user_id);

CREATE POLICY "Users can delete own rows" ON projects FOR DELETE USING (auth.uid() = user_id);

Deze vier beleidsregels dekken 80% van alle individuele gebruikersapps. Voor B2C-apps — consumenten-SaaS, persoonlijke tools, individuele dashboards — is dit je volledige RLS-implementatie.

Multi-tenant workspace beleidsregels

Voor SaaS met teams en workspaces controleer je workspace-lidmaatschap: CREATE POLICY "Workspace members can view projects" ON projects FOR SELECT USING ( workspace_id IN ( SELECT workspace_id FROM workspace_members WHERE user_id = auth.uid() ) );

Dit controleert de workspace_members-koppeltabel bij elke query. Indexeer workspace_members(user_id, workspace_id) voor prestaties.

Voor Nederlandse B2B SaaS-bedrijven met enterprise-klanten: voeg een organisatiehiërarchie toe (bijv. holding → dochteronderneming → afdeling) als extra RLS-dimensie. Het maakt concernrapportage mogelijk met correcte data-isolatie per entiteit.

Rolgebaseerde toegangscontrole

Voeg rolcontrole toe voor beheerdersbewerkingen: CREATE POLICY "Only admins can delete workspace projects" ON projects FOR DELETE USING ( workspace_id IN ( SELECT workspace_id FROM workspace_members WHERE user_id = auth.uid() AND role = 'admin' ) );

Sla rollen op in je workspace_members-tabel (role text DEFAULT 'member'). Rollen: owner, admin, member, viewer.

Voor meer gedetailleerde controle kun je een rechtensysteem (permissietabel) bouwen en specifieke acties controleren in plaats van rollen. Maar begin eenvoudig: owner/admin/member dekt 90% van de B2B SaaS-behoeften.

Veelgemaakte fouten te vermijden

1. Vergeten RLS te activeren op nieuwe tabellen. Maak een checklist: elke nieuwe tabel krijgt RLS geactiveerd voordat deze wordt verbonden met de frontend.

2. De service-rolsleutel gebruiken in de frontend. De service-rolsleutel omzeilt RLS. Stel hem nooit bloot aan gebruikers — gebruik de anon-sleutel in WeWeb/FlutterFlow en de service-rol alleen in server-side Xano-functies.

3. Geen beleid voor INSERT. Veel ontwikkelaars voegen SELECT- en UPDATE-beleidsregels toe maar vergeten INSERT. Zonder dat kunnen anon-sleutelgebruikers helemaal geen rijen aanmaken.

4. N+1-beleidszoekopdrachten. Als je beleid een grote tabel JOIN't bij elke query, zie je prestatieproblemen op schaal. Materialiseer lidmaatschapszoekopdrachten of gebruik indexen agressief. Test altijd de prestaties van je RLS-beleidsregels met representatief datavolume voor lancering. Meer info op de /tools/weweb pagina.