Lovable zelf heeft een aantal goede vangnetten. Bij elke publicatie draait een snelle scan op onder meer de toegangsregels van je database en bekende kwetsbaarheden in pakketten, en op verzoek een diepere scan van je code. Plak je een sleutel in de chat, dan herkent Lovable die en stuurt het je naar een afgeschermde plek voor geheimen. Maar Lovable schrijft zelf dat die scans geen grondige beveiligingscontrole vervangen. Of jouw app veilig is, hangt af van wat er gebouwd is. Loop dus de tien checks uit dit artikel na, zeker als er klantgegevens of betalingen in zitten.

Wat is een goede vibe coding security prompt?

Vraag de AI om je app te beoordelen als een kritische buitenstaander, met een vaste lijst onderwerpen: sleutels in de frontend, toegangsregels per tabel, controles op de server, invoer van buiten, pakketten en logging. Laat hem per punt zeggen wat hij heeft gecontroleerd en waar hij het niet zeker weet. Zo'n prompt vindt vaak de grove fouten. Een AI die zijn eigen werk nakijkt, mist alleen ook dingen. Zie het als eerste ronde, niet als goedkeuring.

Wat is row level security in Supabase?

Row level security (RLS) is een set toegangsregels die in de database zelf draait. Je legt per tabel vast wie welke rijen mag lezen of wijzigen, bijvoorbeeld: een klant ziet alleen zijn eigen bestellingen. Zonder RLS kan iedereen met de openbare sleutel van je project, en die staat altijd in je website, een tabel in principe uitlezen of aanpassen. Supabase adviseert RLS aan te zetten op elke tabel die via de API bereikbaar is. Test daarna met twee testaccounts of de regels echt werken.

Wat is technical debt bij vibe coding?

Technical debt, of technische schuld, is code die nu werkt maar later geld kost: dubbele stukken, onduidelijke structuur, oplossingen die over elkaar heen zijn geplakt. Bij vibe coding groeit die schuld snel, omdat elke nieuwe prompt iets toevoegt zonder dat iemand het geheel overziet. Je merkt het als kleine wijzigingen steeds meer credits kosten of iets anders laten breken. Laat daarom op tijd iemand de code lezen en opruimen, voordat de app te groot is om nog te begrijpen.

Vibe coding security: 10 checks voordat je app live gaat

Vibe coding security komt neer op tien controles voordat je een AI-gebouwde app live zet: geen geheime sleutels in de browser, toegangsregels op elke databasetabel, inloggen en rechten die de server controleert, bijgewerkte pakketten, back-ups die je kunt terugzetten, afspraken over persoonsgegevens, logging en een vaste eigenaar voor het onderhoud. De scanner van je AI-bouwer helpt, maar vervangt geen mens die meekijkt. Jij blijft verantwoordelijk, ook als AI de code schreef.

Vibe coding security: waarom de controle bij jou ligt

Vibe coding is bouwen door te beschrijven wat je wilt, terwijl een AI-tool zoals Lovable, Bolt of Replit de code schrijft en jij die code niet leest. Wat het is en wanneer het past, lees je in vibe coding uitgelegd. Dit artikel gaat over het moment daarna: je app werkt en je wilt hem live zetten.

Een AI-bouwer schrijft code die doet wat je vraagt. Hij test vooral of de normale route werkt: inloggen, iets opslaan, iets terugzien. Beveiliging gaat over de andere route. Wat gebeurt er als iemand je app gebruikt op een manier die jij niet bedoelde? Als hij de adresbalk aanpast, de code in zijn browser bekijkt of je database direct aanspreekt?

De meeste lekken in AI-gebouwde apps zijn daarom geen geavanceerde hacks. Het zijn instellingen: een tabel zonder toegangsregels, een geheime sleutel in de browser, een beheerpagina die alleen verstopt is. Dat valt niet op zolang alles werkt. Het valt pas op als iemand gaat zoeken.

En dan is de vraag wie verantwoordelijk is. Het antwoord is simpel: jij. Je bent eigenaar van de app en, als er persoonsgegevens in staan, verantwoordelijk onder de AVG. Dat de code door AI is geschreven, verandert daar niets aan. Daarom deze tien checks.

De 10 checks voordat je AI-app live gaat

1. Geen geheime sleutels in de browser

Alles wat in de frontend van je app staat, kan een bezoeker zien. Dat is geen theorie: open je site, druk op F12 en zoek in de geladen bestanden. Een geheime sleutel die daar staat, kun je als gelekt beschouwen.

Er zijn twee soorten sleutels. Bij Supabase, de database achter veel Lovable-apps, heet de openbare variant de publishable key (vroeger: anon key). Die mag in de browser staan, maar alleen als je toegangsregels goed zijn (check 2). De secret key (vroeger: service_role key) mag nooit in de browser: hij gaat langs alle toegangsregels heen. Hetzelfde geldt voor sleutels van OpenAI, Stripe of een mailprogramma. Die horen op de server, in een afgeschermde plek voor geheimen. Hoe je een taalmodel veilig via je server aanspreekt, lees je in ChatGPT API op je website.

Zo controleer je het: zoek in de broncode en in de bestanden die je browser laadt op sk-, sb_secret_, service_role en secret. Kijk ook in de code op GitHub, inclusief oude versies. Een sleutel die ooit is gecommit, vervang je, ook als hij nu weg is.

2. Row level security op elke tabel

Row level security (RLS) zijn toegangsregels in de database zelf: wie mag welke rijen lezen, toevoegen of wijzigen. Supabase is daar duidelijk over: een tabel zonder RLS in een bereikbaar schema is leesbaar en schrijfbaar voor iedereen met toegang tot dat schema. En de openbare sleutel staat in je website.

Zet RLS aan op elke tabel en maak per tabel bewuste regels. Staat RLS aan zonder regels, dan geeft de API niets terug met de openbare sleutel. Dat is veilig, maar je app werkt dan niet. Juist daar gaat het vaak mis: een AI-tool die een foutmelding wil oplossen, maakt een regel die iedereen doorlaat. Let ook op twee details uit de documentatie van Supabase: views omzeilen RLS standaard, en gegevens die gebruikers zelf kunnen aanpassen (zoals user_metadata) gebruik je niet om rechten te bepalen.

Zo controleer je het: maak twee testaccounts. Log in als A en probeer via de app en via de API de gegevens van B op te vragen of te wijzigen. Probeer het daarna zonder in te loggen.

3. Inloggen en rechten op de server

Een AI-bouwer verbergt een knop graag voor gebruikers die hem niet mogen zien. Dat is een keuze in de interface, geen beveiliging. De regel is: elke serverfunctie controleert zelf wie er aanroept en of die dat mag, ook functies die je nooit vanuit je eigen scherm aanroept. De diepe scan van Lovable kijkt daar ook naar.

Regel daarnaast de basis van inloggen: bescherming tegen gelekte wachtwoorden als je met e-mail en wachtwoord werkt, en tweestapsverificatie op alle beheeraccounts die bij de app horen: je AI-bouwer, je database, GitHub, je domein en je hosting.

Zo controleer je het: kopieer het adres van een beheerpagina of een API-aanroep en open het in een privévenster, zonder in te loggen. Krijg je iets anders te zien dan een inlogscherm of een foutmelding, dan is het mis.

4. Invoer van buiten is onbetrouwbaar

Controles in het formulier zelf zijn voor het gemak van de gebruiker. Ze beschermen niets, want iemand kan je server ook zonder formulier aanspreken. Controleer invoer daarom op de server: klopt het formaat, mag dit bedrag, past het bestand qua type en grootte?

Zit er een AI-stap in je app, bijvoorbeeld een chatbot of een functie die aanvragen samenvat, dan komt er een risico bij. Tekst van een bezoeker kan je AI proberen te sturen. Hoe dat werkt en hoe je je ertegen wapent, lees je in prompt injection.

5. Afhankelijkheden bijgewerkt en gecontroleerd

Een app bestaat voor een groot deel uit pakketten van anderen. Daar zitten soms bekende kwetsbaarheden in, en AI-tools stellen niet altijd de nieuwste versie voor. Het komt ook voor dat een AI een pakket noemt dat verouderd is of niet bestaat.

Zo controleer je het: draai npm audit of zet de beveiligingsmeldingen van GitHub aan voor je repository. Kijk bij elk pakket dat de AI toevoegt even of het bestaat, wordt onderhouden en echt nodig is.

6. Back-ups die je kunt terugzetten

Een back-up waarvan je niet weet of hij werkt, is een hoop. Weet waar je back-ups staan en test één keer of je kunt terugzetten. Twee valkuilen. Supabase maakt dagelijkse back-ups op de betaalde abonnementen (op Pro kun je zeven dagen terug), maar adviseert gratis projecten zelf regelmatig te exporteren. En geüploade bestanden, zoals foto's en pdf's, zitten niet in die databaseback-ups. Werk je met Lovable Cloud, dan vraag je een export aan via de database-instellingen. Hoe je je data en code buiten één tool veilig stelt, lees je in Lovable exporteren.

7. Persoonsgegevens: afspraken en datalocatie

Bewaar je namen, e-mailadressen of andere persoonsgegevens, dan geldt de AVG. Jij bent verwerkingsverantwoordelijke. Elke partij die gegevens voor je opslaat of verwerkt, is een verwerker: je database, je hosting, je mailprogramma en de AI-aanbieder als je die aanroept. Met elk van hen heb je een verwerkersovereenkomst nodig. Kijk ook waar de gegevens staan. Bij Lovable Cloud kies je bij de start een regio (Amerika, Europa of Azië-Pacific) en die kun je later niet meer wijzigen.

Zet daarnaast in je privacyverklaring wat je app bewaart, waarom en hoe lang. Dit is geen juridisch advies op maat; twijfel je, kijk dan op de site van de Autoriteit Persoonsgegevens of vraag een jurist.

8. Logging en meldingen

Je wilt weten dat er iets misgaat voordat een klant het je vertelt. Zorg voor foutmeldingen die bij een mens aankomen, inzicht in mislukte inlogpogingen en een melding bij ongewoon gebruik. Gebruikt je app een betaald taalmodel, stel dan bij de AI-aanbieder een bestedingslimiet en een melding in. Een sleutel die misbruikt wordt, merk je anders pas op de factuur.

Log niet te veel. Sleutels, wachtwoorden en volledige gesprekken met persoonsgegevens horen niet in je logbestanden.

9. Draai de scanner, en weet wat hij niet ziet

Lovable draait bij elke publicatie een snelle scan op onder meer je toegangsregels en bekende kwetsbaarheden in pakketten. Een diepere scan van al je code start je zelf, bijvoorbeeld vanuit het publicatiescherm. Supabase heeft in het dashboard een Security Advisor die ontbrekende RLS en andere instellingen meldt. Gebruik ze allebei.

Lovable schrijft er in de eigen beveiligingsdocumentatie wel bij dat deze tools geen grondige beveiligingscontrole vervangen en geen volledige veiligheid kunnen garanderen. Een scanner herkent bekende patronen. Hij ziet niet dat een klant in jouw app de prijs van zijn eigen bestelling kan aanpassen, omdat hij niet weet dat dat niet mag. Die bedrijfsregels ken alleen jij.

10. Eén eigenaar voor onderhoud

Een app die live staat, is niet af. Pakketten krijgen updates, je database-aanbieder wijzigt sleutels (Supabase faseert de oude anon- en service_role-sleutels volgens de eigen documentatie eind 2026 uit), en elke nieuwe functie kan een oude regel breken. Een AI die de code schreef, houdt hem niet vanzelf bij.

Spreek af wie dat doet, wie de meldingen krijgt en wie de accounts beheert. Zet die accounts op naam van je bedrijf, niet op die van een freelancer of een medewerker. Wat onderhoud bij een gewone website inhoudt en kost, lees je in website onderhoud; bij een app komt daar de controle van je eigen code bij.

Wat AI goed doet en waar jij nodig bent

Taak	Wat AI goed doet	Waar jij of een developer nodig bent
Sleutels	Herkennen dat een sleutel in de chat staat en je naar een afgeschermde plek sturen	Controleren dat er echt niets in de browser of op GitHub staat
Toegangsregels	Een eerste set RLS-regels voorstellen	Bepalen wie wat mag zien en het testen met twee accounts
Inloggen	Een werkend inlogscherm bouwen	Controleren dat elke serverfunctie de rechten checkt
Pakketten	Een audit draaien en updates voorstellen	Beslissen of een update veilig is en testen na de update
Scans	Bekende patronen snel vinden	Je bedrijfsregels bewaken die geen scanner kent
Privacy	Een opzet voor je privacyverklaring maken	Verwerkersovereenkomsten sluiten en de regio kiezen
Onderhoud	Code aanpassen als je erom vraagt	Weten dát er iets aangepast moet worden

Een vibe coding security prompt: zo laat je AI meekijken

Een AI-tool kan prima een eerste controleronde doen, zolang je hem een vaste lijst geeft en vraagt om eerlijk te zijn over wat hij niet weet. Bijvoorbeeld:

Beoordeel deze app als een kritische beveiligingsspecialist die de code niet zelf heeft geschreven. Loop deze punten één voor één na: 1) staan er geheime sleutels in de frontend of in de repository, 2) heeft elke tabel row level security met regels die passen bij wie de gegevens mag zien, 3) controleert elke serverfunctie wie er aanroept en of die dat mag, 4) wordt alle invoer op de server gecontroleerd, 5) zijn er pakketten met bekende kwetsbaarheden, 6) worden geheimen of persoonsgegevens gelogd. Geef per punt: wat je hebt gecontroleerd, wat je vond, hoe zeker je bent en wat ik zelf moet testen. Pas nog niets aan.

Die laatste zin is belangrijk. Laat de AI eerst rapporteren, beoordeel dan wat je leest en laat daarna pas per punt iets aanpassen. Na elke aanpassing test je opnieuw, want een oplossing voor het ene punt kan een ander punt openzetten. Wil je dat je team zulke afspraken vastlegt, ook over welke gegevens nooit in een AI-tool gaan, gebruik dan het template uit AI-beleid opstellen.

Technische schuld: het risico na de livegang

Beveiliging is niet het enige risico. Elke prompt voegt code toe, en niemand overziet het geheel. Na een paar maanden heb je dubbele functies, oplossingen die over elkaar heen zijn geplakt en een app die bij elke kleine wijziging iets anders laat breken. Dat heet technische schuld.

Je herkent het aan drie signalen. Kleine aanpassingen kosten steeds meer pogingen of credits. Fouten komen terug nadat ze waren opgelost. En niemand kan in een paar zinnen uitleggen hoe de app in elkaar zit. Op dat moment is doorbouwen met prompts vaak duurder dan iemand de code laten lezen en opruimen.

Wanneer je een mens laat meekijken

Voor een prototype dat je aan vijf testgebruikers laat zien, zijn deze tien checks genoeg. Laat een developer of beveiligingsspecialist meekijken zodra een van deze punten geldt:

je bewaart persoonsgegevens van klanten, zoals adressen, dossiers of gezondheidsinformatie;
er lopen betalingen of facturen door de app;
klanten of medewerkers loggen in en zien elk hun eigen gegevens;
de app is gekoppeld aan je boekhouding, CRM of mailbox;
de app wordt de basis van je bedrijf, niet een test.

Lovable raadt dat zelf ook aan voor apps met gevoelige gegevens of belangrijke functies. Draait je site op WordPress in plaats van op eigen code, dan gelden andere maatregelen; die staan in WordPress beveiligen.

Conclusie: AI schrijft de code, jij tekent voor de livegang

Vibe coding security draait niet om dure tools, maar om tien vragen die je stelt voordat je op publiceren drukt. Staan er geen geheime sleutels in de browser? Heeft elke tabel toegangsregels die je zelf hebt getest? Controleert de server wie wat mag? Kun je terugzetten als het misgaat? En wie houdt het bij als de app eenmaal draait?

AI maakt het bouwen sneller en kan zelfs meehelpen met de controle. De verantwoordelijkheid voor wat er live gaat, blijft bij jou. Wanneer je beter stopt met zelf bouwen en wat je dan aan een developer overdraagt, lees je in zelf een app maken met AI. Wil je weten wat een website op maat bij mij kost? Download de prijslijst.

Vibe coding security: 10 checks voordat je AI-app live gaat