Toegangsrechten per tabel
Voor elke tabel moet vastliggen wie welke rij mag lezen, aanpassen of verwijderen. Niet in de interface, maar in de database zelf. Controleer dit opnieuw na elke nieuwe functie.
Je Lovable-app naar productie brengen
Je hebt met Lovable iets gebouwd dat werkt. Je klikt erdoorheen, het doet wat het moet doen, en de volgende stap lijkt klein: live zetten. In de praktijk zit daar het meeste werk. Niet omdat Lovable slecht bouwt, maar omdat een demo andere eisen kent dan een app waar echte gebruikers en hun gegevens in zitten. Hieronder staat wat er dan nog moet gebeuren en waar je de keuze hebt tussen zelf oplossen en overdragen.
01
/
07
Wat er verandert zodra het live gaat
Dezelfde app, andere eisen. Dat verschil is de hele klus.
Zolang je zelf door je app klikt, is er weinig aan de hand. Jij weet welke knoppen je niet moet indrukken, jij vult geldige gegevens in en jij bent de enige die de database ziet. Zodra je de link deelt, valt die bescherming weg. Bezoekers doen dingen die jij nooit zou doen, en sommigen kijken bewust verder dan de interface.
Dat is het kernpunt: Lovable bouwt de interface en de logica die jij beschrijft, maar de vraag wie welke gegevens mag zien is een aparte laag. Die laag zit in je database, niet in je schermen. Een gebruiker die de app niet via jouw knoppen benadert maar rechtstreeks de database bevraagt, komt langs alles wat je in de interface hebt geregeld.
Voor een intern experiment of een demo aan je team is dat prima. Voor een app met klantgegevens, betalingen of persoonsgegevens is het de eerste plek waar je moet kijken. Lees ook of vibe coding klaar is voor productie voor het bredere beeld.
02
/
07
Waar het in de praktijk misgaat
Toegangsrechten op de database zijn het bekendste struikelblok, en niet alleen bij jou.
Lovable gebruikt voor data en inloggen doorgaans Supabase. Daar regel je toegang met Row Level Security: regels die per tabel bepalen welke rij een ingelogde gebruiker mag zien of wijzigen. Staat die beveiliging uit of is de regel te ruim, dan kan iedereen met de publieke sleutel uit je pagina de tabel rechtstreeks uitlezen.
Dat is geen theoretisch scenario. In 2025 werd hiervoor CVE-2025-48757 geregistreerd, een kwetsbaarheid met een hoge ernstscore die precies dit patroon beschrijft bij Lovable-projecten: ontbrekende of ontoereikende Row Level Security, waardoor gegevens zonder inloggen op te vragen waren. De documentatie van Supabase legt uit hoe die regels werken.
Belangrijker dan die ene melding is het mechanisme erachter. Elke keer dat je een nieuwe functie laat bouwen, komt er vaak een nieuwe tabel bij. Die tabel erft je eerdere instellingen niet automatisch. Een app die vorige week netjes dichtzat, kan na een nieuwe functie weer openstaan. Het is dus geen eenmalige controle maar iets dat bij elke uitbreiding terugkomt.
03
/
07
De plekken die aandacht vragen
Vijf onderwerpen komen bij vrijwel elke overgang van demo naar live terug.
Sleutels en secrets
Alles wat in de browser terechtkomt, is leesbaar voor bezoekers. Sleutels met beheerdersrechten horen daar nooit te staan. Die horen aan de serverkant, in omgevingsvariabelen.
Inloggen en sessies
Wachtwoordherstel, bevestiging per mail, hoe lang een sessie geldig blijft en wat er gebeurt bij uitloggen. Dit werkt zelden compleet zonder dat iemand er expliciet naar kijkt.
Foutafhandeling
Wat ziet iemand als een aanvraag mislukt of het internet wegvalt? Zonder afhandeling blijft een scherm leeg of loopt het vast, en jij ziet niet dat het gebeurd is.
Meekijken als het live staat
Je wilt weten dat er iets stukging voordat een gebruiker het meldt. Zonder logging en meldingen merk je storingen pas als iemand belt.
Data die je al hebt
Testdata uit je demo hoort niet in productie. Bepaal wat mee moet, wat weg kan en hoe je later een back-up terugzet als het misgaat.
04
/
07
Wat je zelf kunt oplossen en wat lastiger wordt
Een deel is te doen met de documentatie erbij. Een deel vraagt iemand die het patroon herkent.
Prima zelf te doen
- Toegangsrechten aanzetten op tabellen die je zelf hebt aangemaakt.
- Sleutels uit je paginacode halen en in omgevingsvariabelen zetten.
- Sessieduur en wachtwoordherstel instellen via de standaardopties.
- Testdata opruimen voordat je de link deelt.
Vraagt meestal hulp
- Beoordelen of een toegangsregel echt sluit, of alleen lijkt te sluiten.
- Uitzoeken waarom iets lokaal werkt en live niet.
- Een datamodel rechttrekken dat gaandeweg is gegroeid.
- Bepalen wat er nog meer openstaat dan wat je toevallig gevonden hebt.
05
/
07
Wanneer overdragen slimmer is dan doorbouwen
Niet omdat je het niet kunt, maar omdat de tijd ergens anders meer oplevert.
- Je komt niet meer toe aan de inhoud. Als je dagen kwijt bent aan foutmeldingen in plaats van aan wat je app moet doen, is de bouwfase een rem geworden in plaats van een versneller.
- Je kunt niet beoordelen of iets veilig is. Dat is geen gebrek aan inzet. Het is een specialisme, en het is precies de laag waar de gevolgen het grootst zijn.
- De app groeit sneller dan je overzicht. Elke nieuwe functie raakt iets ouds, en je durft niet meer met zekerheid te zeggen wat er nog werkt.
- Er zit een datum aan. Een demo voor een klant of een gesprek met een investeerder verplaatst zich niet omdat het inloggen nog niet klopt.
06
/
07
Hoe wij hiernaar kijken
Wij bouwen dagelijks met dit soort tools, dus we kennen zowel de snelheid als de rekening.
Lovable is goed in wat het belooft: van een beschrijving naar iets klikbaars, sneller dan je zelf kunt typen. De fout die we vaak zien is niet dat mensen het gebruiken, maar dat ze de demo aanzien voor het eindproduct. Tussen die twee zit werk dat weinig met bouwen te maken heeft en veel met beoordelen.
Zit je vast in dat stuk, dan kun je twee dingen doen. Je kunt zelf de beveiliging nalopen en de code onderhoudbaar maken, of je laat iemand meekijken die dit patroon vaker heeft gezien. Wij doen dat laatste onder vastgelopen met een AI-builder.
Is je app nog niet gebouwd en twijfel je of dit de route is, dan is het gesprek anders. Dan gaat het niet over herstellen maar over scope: welke flow wil je aantoonbaar werkend zien, en wat kan er dan in één werkdag af. Dat is een prettiger startpunt dan achteraf repareren.
07
/
07
Veelgestelde vragen
Kan ik een Lovable-app zomaar live zetten?
Technisch wel, maar je zet dan ook de standaardinstellingen live. Loop in elk geval de toegangsrechten op je database na en controleer of er geen sleutels in je paginacode staan voordat je de link deelt met mensen buiten je eigen team.
Wat is Row Level Security precies?
Dat zijn regels in je database die per tabel bepalen welke rijen een gebruiker mag zien of aanpassen. Zonder die regels regelt alleen je interface de toegang, en een interface kun je omzeilen door de database rechtstreeks te bevragen.
Is Lovable onveilig?
Dat is te kort door de bocht. De tool kan veilige apps opleveren, maar de standaardinstellingen zijn gericht op snel bouwen en niet op live gaan. De beveiliging is werk dat jij of iemand namens jou expliciet moet doen, en dat blijft terugkomen bij elke nieuwe functie.
Moet ik opnieuw beginnen als de basis niet klopt?
Meestal niet. In veel gevallen zijn het gerichte aanpassingen: toegangsregels aanzetten, sleutels verplaatsen, foutafhandeling toevoegen. Opnieuw beginnen is pas logisch als het datamodel zo gegroeid is dat elke wijziging iets anders breekt.
Kan ik de code uit Lovable meenemen?
Lovable werkt met een gewone codebase die je kunt exporteren en koppelen aan je eigen repository. Dat is ook precies wat een andere partij nodig heeft om het over te nemen, dus regel die toegang voordat je iemand laat meekijken.
Wat kost het om dit te laten nakijken?
Dat hangt af van hoe ver de app is en wat je live wilt hebben. Zinniger dan een bedrag is eerst bepalen wat er precies moet werken. Neem contact op en we lopen in een intake door wat er staat en wat er nog nodig is.
