Data afschermen per gebruiker in Lovable zonder gedoe met SQL
Wie een app bouwt met authenticatie wil niet dat gebruikers bij elkaars gegevens kunnen. Met de juiste instructies laat je Lovable automatisch Row Level Security instellen in Supabase, zodat je data waterdicht afgeschermd blijft.
Nadia el Amrani
Bijdrager · lvbl.nl
Het principe van Row Level Security
De oplossing voor dit beveiligingsrisico heet Row Level Security, afgekort tot RLS. Dit is een ingebouwde functie van PostgreSQL, de databasemotor achter Supabase. RLS zorgt ervoor dat de database zelf controleert wie een verzoek uitvoert, nog voordat de data naar de app wordt gestuurd. Als gebruiker A een lijst met facturen opvraagt, kijkt de database welke rijen horen bij het unieke id van gebruiker A. Alle andere rijen worden simpelweg niet teruggegeven. Het grote voordeel hiervan is dat je beveiliging niet afhangt van de code in de frontend. Zelfs als iemand de API-sleutels uit de browser zou vissen en rechtstreeks verzoeken naar Supabase zou sturen, houdt de database de deur dicht.
Waarom Lovable hier soms de mist in gaat
Lovable is getraind om snel werkende interfaces op te leveren. Als je vraagt om een tabel voor projecten, zal de AI de kolommen aanmaken en een koppelbestand schrijven. Soms vergeet de AI echter de RLS-regels in te schakelen, of maakt hij een regel aan die alle acties voor iedereen toestaat. Dat gebeurt vaak onder het motto dat de app anders een foutmelding geeft tijdens het opbouwen. Als bouwer moet je Lovable daarom expliciet opdrachten geven over databescherming. Je moet de AI niet alleen vragen wát er opgeslagen moet worden, maar ook wie er bij mag.
Strikte instructies meegeven bij tabellen
Het voorkomen van beveiligingslekken begint bij je allereerste prompt waarin een tabel wordt geïntroduceerd. Vraag je Lovable om een nieuwe functie met opslag, voeg dan altijd direct de beveiligingseisen toe. Een effectieve aanpak is om te stellen dat elke rij gekoppeld moet zijn aan een `user_id` en dat alleen de eigenaar lees-, schrijf- en verwijderrechten heeft. Vertel Lovable expliciet dat Row Level Security ingeschakeld moet worden met een beleid dat controleert of de ingelogde gebruiker overeenkomt met de kolom in de tabel. Door dit vanaf het begin af te dwingen, voorkom je dat je later door tientallen tabellen moet navigeren om de rechten alsnog recht te zetten.
Werken met gebruikersprofielen
Een klassiek scenario in Lovable is het maken van een profielpagina. Supabase beheert de accounts in een afgeschermd schema genaamd `auth.users`. Omdat je daar vanuit de frontend niet rechtstreeks extra velden zoals een bedrijfsnaam of profielfoto aan kunt toevoegen, maakt Lovable een publieke tabel `profiles` aan. Hier gaat het vaak mis bij het registreren van nieuwe accounts. De gebruiker maakt een account aan, maar de database weigert het profiel op te slaan omdat er nog geen RLS-regel is voor de allereerste invoer. Instrueer Lovable daarom altijd om een trigger in te stellen die bij een registratie automatisch een rij aanmaakt, of zorg voor een expliciete RLS-policy die nieuw geregistreerde gebruikers eenmalig schrijfrechten geeft op hun eigen id.
Openbare data versus afgeschermde data
Niet alle informatie in je applicatie hoeft achter slot en greutel te zitten. Denk aan blogartikelen, productcatalogi of openbare reviews. Voor dit soort tabellen heb je een ander type RLS-regel nodig. Je wilt dat iedereen de gegevens kan lezen, ook bezoekers die niet zijn ingelogd, maar dat alleen beheerders de data kunnen aanpassen. Geef dit helder aan in je instructies aan Lovable. Zeg bijvoorbeeld dat de tabel met producten openbaar leesbaar moet zijn voor alle bezoekers, maar dat wijzigingen alleen toegestaan zijn voor gebruikers met een specifieke beheerdersrol. Lovable zal hierop de juiste SQL-migraties schrijven waarin onderscheid wordt gemaakt tussen lezen en schrijven.
Stappenplan voor het testen van je beveiliging
Vertrouw er nooit blind op dat de AI de beveiliging in één keer goed heeft gezet. Testen is een noodzakelijk onderdeel van het bouwproces. Maak in je app twee verschillende testaccounts aan in twee afzonderlijke vensters van je browser, bijvoorbeeld één normaal venster en één incognitovenster. Voer met het eerste account enkele gegevens in, zoals een taak of een document. Log vervolgens in met het tweede account en controleer of het overzicht leeg is. Zie je de gegevens van het eerste account toch verschijnen, dan weet je dat de RLS-policy te ruim is ingesteld of zelfs helemaal ontbreekt. Je kunt Lovable dan direct vragen om de SQL-policy voor die specifieke tabel te controleren en aan te scherpen.
Fouten herstellen via het Supabase dashboard
Wanneer een pagina in je Lovable-app ineens geen data meer toont of foutmeldingen geeft in de browserconsole, is een RLS-blokkade vaak de boosdoener. De database weigert het verzoek stilzwijgend om de data te beschermen. Je kunt Lovable vragen dit op te lossen, maar soms is het sneller om even in de instellingen van Supabase te kijken onder de tabelinstellingen bij het kopje Policies. Daar zie je precies welke regels er op een tabel actief zijn. Zie je een regel die te beperkend is of een fout bevat, dan kun je de AI de exacte naam van de policy doorgeven met het verzoek deze te vervangen door een correct SQL-script.
Conclusie
Het integreren van een database en authenticatie via Lovable maakt het bouwen van software toegankelijk voor iedereen. Toch blijft de verantwoordelijkheid voor de veiligheid van gebruikersgegevens bij jou als bouwer liggen. Door Lovable vanaf de eerste prompt strak te sturen op Row Level Security, voorkom je dat gevoelige informatie op straat komt te liggen. Maak van RLS een vast onderdeel van je ontwikkelproces op lvbl.nl en test elke tabel consequent met meerdere accounts. Zo bouw je niet alleen snel, maar ook met een gerust hart.
Vond je dit fijn?
Geef een hartje en deel het met een andere Lovable-fan.
