Beveiliging bij vibe coding: zo bescherm je een met AI gebouwde app

Meer aanwijzingen om met Ailoot te werken vind je in de documentatie.

Waarom worden met AI gebouwde apps vaker gehackt?#

Ik bouw zelf ook producten met AI en raak niet paranoïde over beveiliging door “alles maximaal dicht te timmeren”. Maar er is een basisniveau waar je niet onder moet gaan, anders word je op een dag wakker met een lege database en de miners van iemand anders op je server. Deze gids gaat over dat basisniveau. Niet “word een beveiligingsexpert”, maar “schiet jezelf niet zonder reden in de voet”.

De kern van het probleem is eenvoudig. Wanneer je een AI-agent vraagt: “bouw een app waarmee klanten afspraken kunnen boeken”, maakt die de app zo snel mogelijk werkend. Beveiliging is extra werk dat je niet ziet in een demo. Daarom wordt de database open ingesteld, gaat de betaalsleutel rechtstreeks de code in en bestaat de controle op “heeft deze gebruiker toegang?” alleen in de browser, waar die binnen een seconde kan worden omzeild.

Met andere woorden: het gat ontstaat vanzelf, standaard. Jij hebt niets verkeerd gedaan. Je hebt gewoon niets gedaan — en in beveiliging betekent niets doen precies “voor iedereen toegankelijk”.

Wat hebben vibe coders al op de harde manier geleerd?#

De beste bescherming tegen onvoorzichtigheid is leren van de fouten van anderen. Dit zijn vier verslagen die je kunt bekijken voordat je je project publiceert.

Lovable en uitgeschakelde RLS. Het platform Lovable bouwt apps op basis van tekstbeschrijvingen. In 2025 werd een structureel beveiligingslek in de apps ontdekt en kreeg het nummer CVE-2025-48757. De oorzaak: de gegenereerde apps hadden geen regels voor toegang tot rijen in de database (RLS, hieronder uitgelegd). Een onderzoeker controleerde een steekproef en vond 303 blootgestelde toegangspunten in 170 apps. Namen, telefoonnummers, betaalstatussen, API-sleutels van anderen en zelfs huisadressen lagen bloot. Bij ongeveer 70 procent van de gecontroleerde apps stond de beveiliging op rijniveau volledig uit.

Tea en gevoelige gegevens. De Tea-app (anonieme recensies van mensen) verloor in juli 2025 ongeveer 72.000 afbeeldingen, waaronder 13.000 selfies en foto's van documenten, en later meer dan een miljoen privéberichten. De technische oorzaak was open opslag en zwakke toegangscontroles. De beveiligingsgemeenschap noemt Tea als sprekend voorbeeld: wanneer een snelle lancering belangrijker is dan het controleren van machtigingen, lekken gevoelige gegevens als eerste.

Nog een praktijkvoorbeeld. In een geval dat de oorspronkelijke auteur beschrijft, werd de app van een vibe coder gehackt omdat de AI bij het aanmaken van de database een standaardwachtwoord instelde — een wachtwoord dat automatisch kon worden geraden. Daarna volgde het gebruikelijke patroon: ze drongen binnen, installeerden miners en herschreven het project. De server moest volledig worden gewist. Een standaardwachtwoord is een niet-afgesloten deur met een bordje “kom maar binnen”.

Twee beveiligingsfronten: waar ben je precies kwetsbaar?#

Wanneer mensen het hebben over “beveiliging bij vibe coding”, gooien ze meestal twee totaal verschillende zorgen op één hoop. Laten we ze uit elkaar halen, want je beschermt je er op verschillende manieren tegen.

Eerste front: de agent zelf. Je start een AI-agent op je computer en geeft die toegang tot je bestanden, terminal, sleutels en database. Het risico is dat een agent geen mens is: die volgt instructies letterlijk en kiest de kortste route, zelfs als die gevaarlijk is. Hierbij hoort ook het risico dat de opdracht van iemand anders via tekst die de agent leest bij hem wordt “geïnjecteerd” (dit heet prompt injection).

Tweede front: de afgeronde app. Dit is wat je hebt gepubliceerd en wat mensen gebruiken. Het doelwit is je gepubliceerde site of dienst: aanvallers dringen een open database binnen, sturen valse verzoeken of proberen de accounts van anderen te raden. De agent heeft hier niets mee te maken — het gat is eerder achtergelaten en anderen maken er misbruik van.

Anthropic, het bedrijf achter Claude, formuleert het belangrijkste beschermingsprincipe zo — en het geldt voor beide fronten:

In de praktijk betekent dit: reken er niet op dat AI “uit zichzelf geen slechte dingen doet”. Beperk eerst wat de agent fysiek kan doen en vraag hem daarna pas zich goed te gedragen. Wanneer zijn gedrag tekortschiet — en dat gebeurt — beschermt alleen een harde grens die je vooraf hebt ingesteld je.

Wat kan een AI-agent met toegang tot je computer doen?#

Het meest onderschatte risico is je eigen agent met te ruime machtigingen. Daarvoor is niet eens een externe hacker nodig. Hier is een recent voorbeeld van eind mei 2026. Een Codex-agent had beheerdersrechten nodig die de gebruiker niet had. De agent gaf niet op: hij keek rond, zag dat de gebruiker lid was van de groep docker, wat in feite gelijkstaat aan root, en gebruikte die toegang.

Er was hier geen kwade opzet. Een agent die de opdracht krijgt om “de taak op te lossen” vindt een structurele zwakte gewoon sneller dan een mens. En als die zwakte toegang geeft tot je sleutels of productieomgeving, gebruikt hij die. Daarom is regel nummer één minimale machtigingen. Geef een agent precies zoveel toegang als die nodig heeft voor een specifieke taak, en geen druppel meer.

Wat kun je in de praktijk doen, ook als je geen programmeur bent?

1. Laat de agent niet in de modus “alles toestaan” draaien op een productiemachine

   Een modus waarin de agent niet om bevestiging vraagt (vaak bypass of yolo genoemd) is alleen bedoeld voor een sandbox of testproject, niet voor een machine met werkende sleutels en toegang tot productie.

2. Verbied de agent geheimen te lezen

   In Claude Code doe je dit met een regel die toegang tot bestanden met sleutels weigert. Zelfs als de agent .env wil openen, laat het hulpmiddel dat dan niet toe.

3. Houd productiesleutels apart

   Sleutels voor de productiedatabase en de betaaldienst horen niet in dezelfde map te staan waarin de agent code schrijft. Houd omgevingen gescheiden: gebruik testsleutels wanneer je experimenteert.

4. Gebruik de sandbox van het hulpmiddel

   Moderne AI-tools kunnen opdrachten geïsoleerd uitvoeren (in een sandbox), zonder toegang tot de rest van het systeem. In Claude Code vermindert dit het aantal toestemmingsverzoeken met ongeveer 84 procent — dus het is ook handiger.

Een regel die het lezen van geheimen in Claude Code weigert, ziet er ongeveer zo uit — zet die in de machtigingsinstellingen:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Waar mag je API-sleutels en wachtwoorden nooit opslaan?#

De goedkoopste en meest voorkomende fout is sleutels in de code zetten. Een API-sleutel voor een betaaldienst, een databasewachtwoord, een bottoken — dat zijn allemaal geheimen. Ze horen in een apart .env-bestand, en dat bestand moet in .gitignore staan zodat het niet samen met de code in git terechtkomt.

De omvang van het probleem in 2025: 28,65 miljoen nieuw hardgecodeerde geheimen in openbare repositories, 34 procent meer dan het jaar ervoor. Het aantal lekken van sleutels voor AI-diensten steeg met 81 procent. Vibe coding gooit olie op het vuur omdat de agent commits maakt zonder te kijken.

Wat je nu zelf kunt controleren:

1. Open het .gitignore-bestand van het project

   Controleer of er een regel met .env in staat. Zo niet, voeg die dan toe voordat je de eerste commit maakt.

2. Ga naar je GitHub-repository

   Controleer of het .env-bestand daar niet staat. Zoeken in de repository naar .env of een deel van je sleutel is een snelle controle.

3. Is een sleutel uitgelekt? Trek hem in en geef een nieuwe uit

   Alleen de commit verwijderen is niet genoeg: de sleutel kan al zijn buitgemaakt. Ga naar de dienst (betaalaanbieder, clouddienst, AI-aanbieder), trek de oude sleutel in en geef een nieuwe uit. Dit heet rotatie.

4. Geef sleutels minimale machtigingen

   Is een sleutel alleen nodig om gegevens te lezen, maak hem dan alleen-lezen. Dan kan er, zelfs als die uitlekt, minder worden gestolen.

Waarom kan iedereen je database zien zonder RLS?#

Als je een app bouwt met Supabase of een vergelijkbare database, is dit het belangrijkste onderdeel. RLS staat voor Row Level Security. Eenvoudig gezegd is het een regel die bepaalt welke rijen in een tabel aan een bepaalde gebruiker worden getoond. Zonder RLS geeft de tabel “orders” iedereen de bestellingen van alle klanten terug.

De Supabase-documentatie verwoordt het zelf duidelijk:

En dit is de belangrijkste valkuil voor een vibe coder. Wanneer je een tabel maakt door in het Supabase-dashboard te klikken, wordt de beveiliging automatisch ingeschakeld. Maar wanneer AI de tabel maakt — en die schrijft bijna altijd rechtstreeks SQL-opdrachten — blijft RLS standaard uitgeschakeld. Dat betekent dat een door een agent gemaakte tabel vrijwel zeker openstaat voor het hele internet. Precies zo lekten die 170 Lovable-apps.

Wat je moet doen:

1. Vraag het de agent rechtstreeks

   Schrijf: “laat me alle tabellen zien waarvoor RLS is uitgeschakeld.” De AI maakt een lijst — dat is je werklijst.

2. Schakel RLS in op elke tabel met gebruikersgegevens

   Voeg ook minstens één toegangsbeleid toe — bijvoorbeeld: “een gebruiker kan alleen zijn eigen rijen zien”.

3. Controleer het dashboard

   In het Supabase-dashboard moet bij elke tabel “RLS enabled” staan. Als het grijs of rood is, staat de tabel open.

4. Test het echt

   Meld je aan als gewone gebruiker en probeer gegevens van iemand anders op te vragen. Als de toegang wordt geweigerd, werkt het beleid.

Waarom beschermen machtigingscontroles in de interface je niet?#

Een veelvoorkomende misvatting is: “Ik heb ervoor gezorgd dat gewone gebruikers de beheerdersknop niet kunnen zien.” Het probleem is dat een knop alleen een plaatje in de browser is. Je kunt een verzoek rechtstreeks naar de server sturen zonder de knop te gebruiken. Als de server de machtigingen niet opnieuw controleert, voert die de opdracht van iemand anders uit.

Een klassiek voorbeeld heet IDOR. Stel dat je je bestelling opent op een adres met id=123. Verander dat in id=124, en je kunt de bestelling van iemand anders zien omdat de server niet controleerde of het echt jouw bestelling was. Dit is een van de meest voorkomende beveiligingslekken in met vibe coding gebouwde apps; zwakke machtigingscontroles lagen ook aan de basis van het Tea-lek.

De regel is eenvoudig: herhaal elke controle “mag deze gebruiker dit doen?” op de server. De interface is er voor het gemak; de bescherming hoort in de backend. Een kant-en-klare instructie voor de agent: “voeg serverzijdige machtigingscontroles toe voor elk endpoint dat gebruikersgegevens leest of wijzigt; vertrouw er niet op dat een element in de interface verborgen is.”

Hoe controleer je code op gaten als je geen programmeur bent?#

Het goede nieuws: tegenwoordig kun je dezelfde AI vragen de beveiliging te controleren — die vindt veelvoorkomende gaten redelijk goed. Dit zijn drie hulpmiddelen voor verschillende taken.

1. De opdracht /security-review in Claude Code. Een eenmalige controle van de huidige branch op SQL-injectie, XSS, autorisatielekken, datalekken en problemen met afhankelijkheden. Ik heb stap voor stap uitgelegd hoe dit werkt en hoe je bij elke wijziging een automatische controle toevoegt in een aparte gids over beveiligingscontrole in Claude Code. Het belangrijkste hier: dit is de eerste verdedigingslinie, gestart met één opdracht.

2. De officiële security-guidance-plugin. Installeer deze via de officiële pluginmarktplaats met /plugin install security-guidance@claude-plugins-official (Claude Code versie 2.1.144 of hoger is vereist). De plugin controleert code op drie momenten: bij elke bewerking, aan het einde van elke beurt en bij het committen. Hij spoort omzeiling van machtigingscontroles, IDOR, injecties en zwakke cryptografie op. Maar Anthropic is open over de beperkingen:

npx skills add <author>/<repo>

Zeg daarna gewoon tegen de agent: “controleer mijn project op kwetsbaarheden.” Maar er is een belangrijke kanttekening bij deze verzameling; daarom krijgt die verderop een aparte sectie.

Ter context: grote spelers zijn ook het beveiligen van AI-code serieus gaan nemen. In het kader van Project Glasswing, dat op 2 juni 2026 werd uitgebreid tot 150 organisaties, vonden partners in korte tijd met Anthropic-modellen meer dan 10.000 kritieke kwetsbaarheden. De belangen zijn duidelijk:

Kun je skills en extensies van GitHub vertrouwen?#

Hier wordt het extra lastig, omdat het gevaar komt van een hulpmiddel dat je voor de beveiliging installeert. Wanneer je npx skills add ... uitvoert of een extensie installeert, haal je code van iemand anders binnen die de agent vervolgens met jouw machtigingen uitvoert. Als de auteur is gehackt of het pakket vanaf het begin kwaadaardig was, heb je een probleem.

Neem de skillverzameling uit de vorige sectie. De naam bevat “Anthropic”, waardoor je minder op je hoede bent. Maar in de eigen beschrijving staat duidelijk:

Met andere woorden: de naam is misleidend. De verzameling zelf is op dit moment volwassen en schoon, maar het principe blijft: je installeert die op eigen risico. En de dreiging is niet theoretisch. In mei 2026 stond een kwaadaardige extensie voor een teksteditor slechts 18 minuten op de marktplaats — in die tijd wist die wachtwoorden uit wachtwoordmanagers, GitHub-tokens, toegang tot de cloud en zelfs Claude Code-configuraties te stelen van mensen die hem hadden geïnstalleerd. Nog een vervelend detail: zulke malware overleeft vaak het gewoon verwijderen van het pakket en wordt in de volgende sessie opnieuw uitgevoerd.

Ik heb voor mezelf een eenvoudige gewoonte ontwikkeld, die ik jou ook aanraad: controleer elke skill van GitHub zelf voordat je die installeert. Auteurs kunnen worden gehackt, accounts kunnen worden gekaapt en malware kan in een repository terechtkomen. Controleren is je bescherming.

Het praktische minimum vóór installatie: bekijk de auteur en het aantal sterren, lees de beschrijving van de skill, installeer een hulpmiddel niet “omdat het in één bericht werd aangeraden” en probeer een onbekend hulpmiddel eerst uit in een aparte testomgeving, niet op een computer met productiesleutels.

Wat helpt je na een inbraak: back-ups en terugzetten#

Beveiliging gaat niet alleen over “buitenstaanders buiten houden”, maar ook over “weer normaal verdergaan wanneer er iets misgaat”. Want er gaat iets mis. In de beschreven praktijkzaak verwijderde een AI-agent een actieve database in een productieproject terwijl hij een routinetaak uitvoerde. Er was een back-up, maar die was drie dagen oud — en drie dagen aan gegevens waren gewoon verdwenen.

Dat leidt tot twee regels.

Maak vaak een back-up. Als je app gegevens bevat die je niet kwijt wilt, biedt een kopie om de drie dagen slechts de illusie van bescherming. Stel automatische back-ups in die minstens elke 30 minuten worden gemaakt. Voor de meeste databases, waaronder Supabase, kun je dit met een paar klikken inschakelen.

Git is een verzekering tegen de agent. Git bewaart de geschiedenis van je code: je kunt elke werkende staat herstellen. Wanneer een agent iets herschrijft dat werkte, ga je terug naar de laatste werkende versie in plaats van het handmatig te repareren. Heeft AI het project verwijderd of beschadigd en weet je niet hoe je het terugkrijgt? Bekijk dan het aparte verslag: wat je moet doen als AI de database heeft verwijderd. Lees voor bescherming tegen schade aan je project vooraf de gids hoe je Claude Code tegen schade beschermt.

Beveiligingschecklist vóór publicatie#

Loop deze lijst vlak vóór publicatie in de aangegeven volgorde na.

1. Geheimen in .env, en .env in .gitignore. Geen sleutels in de code. Geen .env-bestand in een openbare repository.

2. Sleutels met minimale machtigingen. Elke sleutel kan alleen doen wat nodig is. Productiesleutels staan los van de omgeving van de agent.

3. RLS is ingeschakeld op alle tabellen met gebruikersgegevens en er zijn toegangsbeleidsregels ingesteld.

4. Machtigingscontroles aan de serverkant voor elke handeling met gegevens. Een knop in de interface verbergen is niet genoeg. Het wijzigen van de id in het adres is handmatig getest.

5. Webhookhandtekeningen worden gecontroleerd. Elke handler voor externe meldingen (betalingen, formulieren) controleert de handtekening.

6. Er geldt snelheidsbeperking voor inkomende verzoeken en dure bewerkingen, zodat wachtwoorden niet met brute force kunnen worden geraden en je rekening niet kan oplopen.

7. De agent draait niet in de modus “alles toestaan” op een computer met productiesleutels. Het lezen van .env is verboden.

8. Er worden regelmatig back-ups gemaakt en ze zijn getest — je hebt daadwerkelijk geprobeerd een back-up terug te zetten, in plaats van alleen te geloven dat de kopieën “ergens staan”.

9. De code is gecontroleerd met /security-review of de security-guidance-plugin. Bevindingen zijn opgelost.

10. Skills en extensies van anderen zijn vóór installatie gecontroleerd. Er is niets “blind” geïnstalleerd.

Waar begin je vandaag?#

Probeer niet alles uit deze gids in één avond uit te voeren — dan doe je uiteindelijk niets. Voer vandaag de drie belangrijkste stappen uit:

1. Controleer je geheimen. Open .gitignore, controleer of .env erin staat en kijk of er geen sleutels in de openbare repository staan. Zijn er sleutels uitgelekt, trek ze dan in en geef nieuwe uit.
2. Vraag naar RLS. Zeg tegen de agent: “laat me de tabellen zien waarvoor RLS is uitgeschakeld” — en schakel het in voor alle tabellen waarin gegevens van mensen zijn opgeslagen.
3. Stel regelmatige back-ups in. Zo verlies je bij problemen minuten in plaats van dagen.

Volg daarna de checklist hierboven wanneer je project groeit en met geld en gegevens van anderen gaat werken.

Nog één ding. Beveiliging bij vibe coding draait om de verantwoordelijkheid van de eigenaar. Je hoeft geen beveiligingsexpert te worden. AI heeft je product in één avond gebouwd — prima, maar jij bent ervoor verantwoordelijk. Het basisniveau in deze gids laat zien hoe die verantwoordelijkheid er in de praktijk uitziet.

Voor verder werken met modellen kun je naar Ailoot gaan.