Pak je publieke sleutel
Die staat in de code die je browser laadt. Zoek in je project naar 'anon' of 'public key'; hij is niet geheim en hoort dat ook niet te zijn.
Je database staat open
Een AI-bouwer zet in een uur een werkende app neer met inlog, database en hosting. Wat hij er standaard niet bij zet, is de regel die bepaalt wie welke rij mag zien. Het gevolg: iedereen met een browser kan bij alles.
01/10
Waarom dit zo vaak misgaat
Een app zonder rechtenregels werkt perfect. Dat is nou juist het probleem.
Moderne bouwplatformen praten vanuit de browser rechtstreeks met de database. Dat is snel en het bespaart een hele laag code. De prijs is dat de database zelf moet bepalen wie wat mag zien, want er zit geen server meer tussen die dat voor je doet.
Die regels heten rechten op rijniveau, en ze staan standaard uit. Zet je ze niet aan, dan werkt je app precies zoals je verwacht: jij logt in, jij ziet jouw gegevens. Wat je niet ziet, is dat iemand anders met dezelfde sleutel ook jouw gegevens kan opvragen — die sleutel staat namelijk gewoon in de code die je browser heeft geladen.
In mei 2025 werd hier een kwetsbaarheid voor uitgeschreven, en bij een controle in maart 2026 bleek dat honderdzeventig live apps op die manier open stonden. Niet omdat de bouwers slordig waren, maar omdat er niets was dat waarschuwde.
02/10
Hoe dat er in de praktijk uitziet
- Een startpagina die in januari 2026 live ging, lekte binnen tweeënzeventig uur anderhalf miljoen inlogsleutels en vijfendertigduizend e-mailadressen. De hele app was uit gesprekken met een AI-assistent ontstaan, zonder dat iemand de code had gelezen.
- Een app die privéberichten aan de verkeerde gebruikers toonde, omdat de toegangscontrole was gegenereerd zonder dat iemand naar de logica keek.
- Wat deze gevallen delen: de app deed het. Er was geen foutmelding, geen crash, geen signaal. Alleen een deur die openstond.
03/10
Waarom een AI-bouwer dit niet uit zichzelf doet
Het is geen fout in het gereedschap, het is een keuze in de standaardinstelling.
Een database die standaard alles dichtzet, is voor een bouwer die net begint een muur. Niets werkt, en de foutmelding vertelt niet dat je rechten mist maar dat er geen rijen zijn. Dat is de reden dat platformen dit standaard uit laten staan: de eerste vijf minuten moeten soepel verlopen.
Voor een gesprek met een AI-bouwer werkt dat door. Jij vraagt om een app die werkt, hij levert een app die werkt. Er is geen moment waarop iemand vraagt of dit ook af mag zijn voor de buitenwereld, want dat was niet de opdracht.
Sommige platformen zijn hier inmiddels op aangepast en waarschuwen wanneer een tabel zonder regels naar buiten komt. Reken er niet op dat jouw platform dat doet, en controleer het zelf — dat kost minder tijd dan uitzoeken of de waarschuwing bestaat.
04/10
Zelf controleren, in tien minuten
Vraag een tabel op
Doe met die sleutel een verzoek aan je database zonder in te loggen. Krijg je rijen terug, dan kan iedereen dat.
Herhaal per tabel
Rechten staan per tabel aan of uit. Eén goed ingestelde tabel zegt niets over de rest.
05/10
Wat je daarna instelt
Niet één schakelaar, maar per tabel een antwoord op wie wat mag.
Rechten op rijniveau aanzetten is de eerste stap en meteen de meest brute: zodra je hem omzet, ziet niemand meer iets. Dat is de bedoeling. Daarna schrijf je per tabel de regels die wél mogen, en dat dwingt je om op te schrijven wie waar bij hoort te kunnen.
Voor de meeste apps is dat kort: een gebruiker mag zijn eigen rijen zien en wijzigen, en verder niets. Voor apps met teams of organisaties wordt het een regel over lidmaatschap. Dat is denkwerk van een halfuur, geen project.
Let bij het testen op één ding dat vaak wordt overgeslagen: controleer niet alleen dat jij je eigen gegevens ziet, maar ook dat je die van een ander níet ziet. Dat tweede is de test die er werkelijk toe doet.
06/10
De vier plekken waar het alsnog misgaat
Rechten aanzetten is de helft; ze kloppend houden is de andere helft.
De eerste is een nieuwe tabel. Rechten staan per tabel, dus een tabel die er volgende maand bij komt, staat weer open. Neem dit op in je vaste rondje voor het live zetten.
De tweede is een dienstsleutel die in de browser belandt. Naast de publieke sleutel bestaat er een sleutel die alle regels overslaat, bedoeld voor servercode. Zodra die in code terechtkomt die de bezoeker downloadt, is alles wat je hebt ingesteld betekenisloos.
De derde is een weergave of functie die de regels omzeilt. Een handige samenvattingsweergave kan gegevens uit meerdere tabellen halen zonder dat de rechten van die tabellen meereizen.
De vierde is een bestandsopslag. Afbeeldingen, cv's en bijlagen zitten meestal niet in de database maar in een aparte opslag, met een eigen rechtenmodel dat je apart moet instellen.
07/10
Wat je AI-bouwer hier wel en niet doet
Wel zinvol
- De tabellen aanmaken en de app eraan koppelen
- Op verzoek regels genereren als je er expliciet om vraagt
- Uitleggen wat er staat als je het vraagt
Niet zinvol
- Uit zichzelf waarschuwen dat de deur openstaat
- Beoordelen of jouw regels kloppen voor jouw situatie
- Merken dat een latere wijziging de rechten omzeilt
08/10
Waarom dit erger is dan een gewoon lek
Bij een klassiek lek moet iemand iets vinden: een fout in de code, een verkeerde instelling op een server. Hier hoeft dat niet. De sleutel ligt in de browser, de database staat op internet, en de vraag is één regel.
Daar komt bij dat het pas opvalt als het al mis is. Er is geen moment waarop je app het niet doet, dus er is ook geen moment waarop je gaat kijken. De apps die dit overkwam, draaiden allemaal prima tot iemand van buiten de sleutel gebruikte.
Dat maakt het een van de weinige dingen die je écht moet controleren voordat je iets live zet, ook als het maar een proefversie voor tien testers is. Tien testers hebben ook echte e-mailadressen.
09/10
Hoe wij dit op een bouwdag doen
Voordat er iets naar buiten gaat, doen we de controle hierboven met de publieke sleutel, per tabel. Dat kost een paar minuten en het is de enige manier om zeker te weten dat het dicht zit.
Wat we daarnaast vastleggen: welke tabellen bewust openbaar zijn. Er zijn er meestal een paar — een lijst met openbare pagina's, een prijstabel — en die uitzondering wil je opgeschreven hebben. Anders staat er over een half jaar iets open waarvan niemand meer weet of dat de bedoeling was.
10/10
Veelgestelde vragen
Geldt dit alleen voor Supabase?
Nee. Elk platform waarbij de browser rechtstreeks met de database praat, heeft dit patroon. De naam van de instelling verschilt, het principe niet.
Mijn app heeft inlog. Ben ik dan niet veilig?
Niet automatisch. Inloggen bepaalt wie je bent; rechten op rijniveau bepalen wat je mag zien. Zonder dat tweede kan een ingelogde gebruiker de gegevens van alle andere gebruikers opvragen.
Wat als ik de publieke sleutel geheim houd?
Dat kan niet. Hij staat in de code die elke bezoeker downloadt. Hij hoort ook niet geheim te zijn; de bescherming moet van de rechtenregels komen.
Moet ik dit ook doen voor een prototype?
Als er echte gegevens in staan, ja. Testgebruikers geven vaak hun echte e-mailadres, en dat is precies wat er in de bekende gevallen op straat lag.
Kan ik dit later nog aanzetten?
Ja, en dat is meteen het advies: doe het liever laat dan niet. Reken erop dat je app na het aanzetten eerst niets meer laat zien, en dat je per tabel de regels moet toevoegen.
Hoe weet ik of er al iemand bij is geweest?
Meestal niet met zekerheid. Wat je wel kunt doen is de toegangslogs van je database opvragen en kijken of er verzoeken staan die niet van je eigen app komen.
