Eerst de disclaimer die je waarschijnlijk niet verwacht: wij bouwen zelf elke dag met AI. Deze site ook, onze klantprojecten ook. Het beste stuk gereedschap dat er in twintig jaar bij is gekomen.
Dit is dus geen verhaal over hoe gevaarlijk AI is. Het gaat over wat er ontbreekt als niemand meer over de schouder meekijkt.
Want dat is wat er veranderd is. Een ondernemer zonder technische achtergrond bouwt nu in een weekend een webshop met inlog, database en betaalpagina. Fantastisch. Alleen heeft in dat weekend niemand gecontroleerd of die database op slot zit.
Waarom levert AI wel werkende code op, maar niet automatisch veilige code?
Omdat werkend en veilig twee verschillende dingen zijn, en AI alleen op het eerste wordt afgerekend. Je vraagt om een contactformulier dat mails verstuurt. Je krijgt een contactformulier dat mails verstuurt. Het werkt, en daarmee is de opdracht klaar.
Wat je niet vraagt, omdat je niet weet dat het bestaat: of dat formulier bestand is tegen iemand die er iets anders in typt dan een naam.
Een ervaren developer stelt die vraag wel. Niet omdat hij slimmer is, maar omdat hij ooit heeft meegemaakt wat er gebeurt als je die vraag overslaat. Die laag ontbreekt, en die laag heet review.
Eerlijk erbij: een mens zonder security-kennis maakt dezelfde fouten. Het verschil is de schaal. Bouwen ging tien keer sneller, controleren niet.
Lek 1: kan iedereen zomaar bij mijn database?
Vaker wel dan je denkt. De databasediensten die AI-builders standaard voor je opzetten, laten je browser rechtstreeks met de database praten. De sleutel daarvoor zit gewoon in je website, en dat hóórt ook zo. Het probleem is wat er achter die sleutel gebeurt.
De beveiliging zit namelijk in de database zelf, in regels die per tabel bepalen wie welke rij mag zien. Staan die regels uit, dan kan iedereen die de sleutel uit je broncode plukt de hele tabel opvragen. Alle bestellingen, alle e-mailadressen, zonder dat er iets gehackt hoeft te worden.
AI slaat dit over omdat het aanzetten van die regels je app meteen breekt. Zonder toegangsregels is je scherm ineens leeg en denk je dat er iets stuk is. De snelste weg naar "het werkt weer" is ze uit laten staan.
Zelf controleren: log in op het dashboard van je databaseleverancier en kijk naar je tabellen. Een tabel zonder actieve regels wordt daar meestal expliciet als onbeperkt of onbeveiligd aangemerkt. Zie je dat bij een tabel met klantgegevens, dan weet je genoeg.
Lek 2: wat gebeurt er als iemand code invult in mijn formulier?
In het beste geval niets, in het slechtste geval draait die code straks in de browser van je volgende bezoeker. Dat heet cross-site scripting. Het speelt bij alles wat een bezoeker intypt en wat later weer getoond wordt: een reactie, een review, een profielnaam.
Toont jouw site die invoer als tekst, dan is er niks aan de hand. Toont hij het als code, dan voert de browser het uit. Die code leest mee met wat je bezoeker invult en kan zijn sessie overnemen.
Het verraderlijke is dat moderne frameworks dit standaard goed doen, waardoor niemand er nog over nadenkt. Het gaat mis op de uitzondering: vraag je om opgemaakte tekst te tonen, dan komt er een functie uit die de beveiliging bewust uitzet. Zo'n functie heeft in de meeste frameworks het woord "dangerously" in de naam, precies om deze reden. AI gebruikt hem omdat je het gevraagd hebt en omdat het werkt.
En let op: een controle die alleen in het formulier zit, is geen controle. Die omzeil je door het onderliggende adres rechtstreeks aan te roepen. Valideren hoort op de server.
Zelf controleren: hiervoor heb je iemand nodig die code kan lezen. Vraag je bouwer waar bezoekersinvoer als opgemaakte HTML wordt getoond en wat die invoer filtert. Een vaag antwoord is ook een antwoord.
Lek 3: wat zijn security headers, en heeft mijn site ze?
Security headers zijn korte instructies die je server met elke pagina meestuurt en die de browser vertellen wat er wel en niet mag. Ze kosten niets en ontbreken bijna altijd op snel gebouwde sites.
De vier die ertoe doen:
HSTS dwingt af dat je site altijd via een beveiligde verbinding laadt. Zonder deze regel is de eerste verbinding van een bezoeker te onderscheppen, ook al heb je een geldig SSL-certificaat.
CSP, voluit Content Security Policy, bepaalt welke scripts er op jouw pagina mogen draaien. Dit is je vangnet als lek 2 misgaat.
X-Frame-Options voorkomt dat iemand jouw site in een onzichtbaar kadertje op zijn eigen pagina zet en de klikken van je bezoekers afvangt. Tegenwoordig regel je dat via frame-ancestors in je CSP.
X-Content-Type-Options houdt de browser ervan af zelf te gokken wat voor bestand hij binnenkrijgt, en dat is precies waar een geüpload bestand misbruik van maakt.
AI slaat ze over omdat ze in een configuratiebestand horen dat verder niets zichtbaars doet. Niemand vraagt om een Content Security Policy, want daarvoor moet je weten dat die bestaat. En de site ziet er zonder headers precies hetzelfde uit.
Zelf controleren: ga naar securityheaders.com, vul je eigen domein in en scan. Je krijgt een cijfer van A+ tot F en een lijst van wat er ontbreekt. Een F betekent niet dat je gehackt bent, wel dat er geen vangnet gespannen staat.
Lek 4: is een verborgen knop hetzelfde als een beveiligde pagina?
Nee, en dit is het hardnekkigste misverstand van de vijf. Een knop die alleen zichtbaar is voor beheerders zegt niets over wie die actie kan uitvoeren. De knop is het bordje op de deur, niet het slot.
Achter elke knop zit een adres op je server dat het werk doet. Verberg je alleen de knop, dan blijft dat adres bereikbaar voor wie het kent. En die adressen staan gewoon in de code die elke bezoeker binnenhaalt.
Hetzelfde geldt voor gegevens die bij één klant horen. Staat jouw factuur op een adres dat eindigt op 1002, dan is 1003 die van iemand anders. Controleert de server niet of jij daar recht op hebt, dan krijg je hem te zien.
AI slaat dit over omdat jouw opdracht over het scherm ging. "Alleen beheerders zien deze knop" is een ontwerpvraag en wordt in het ontwerp opgelost. Dat dezelfde controle ook op de server hoort, stond er niet bij.
Zelf controleren: open een privévenster en plak daar het adres van een pagina van je eigen site die alleen voor ingelogde gebruikers bedoeld is. Zie je de inhoud, dan zit je beveiliging alleen in het menu. Doe dit alleen op je eigen site.
Lek 5: staan mijn API-sleutels in de code die bezoekers downloaden?
Als je dat niet zeker weet, is het het controleren waard. API-sleutels zijn de wachtwoorden waarmee je site praat met andere diensten: je mailprovider, je betaaldienst, je AI-leverancier. Ze horen op de server te blijven. Belanden ze in de code die de browser binnenhaalt, dan liggen ze op straat.
Frameworks regelen dat met een voorvoegsel in de naam van de instelling. Alles waar het woord "public" in staat gaat mee naar de browser, de rest blijft op de server. Prima systeem, tot het moment dat er een foutmelding komt dat een sleutel niet gevonden wordt.
Want de snelste manier om die melding weg te krijgen, is dat voorvoegsel ervoor plakken. Dan werkt het. AI stelt dat ook voor, want het lost het gemelde probleem op. Dat je zojuist je mailsleutel hebt gepubliceerd, merkt niemand, want niemand leest die gedownloade JavaScript.
De impact is direct in geld te meten: iemand verstuurt mail namens jouw domein of verbruikt je AI-tegoed. Jouw sleutel, jouw rekening.
Zelf controleren: open de instellingen van je project bij je hostingpartij. Loop elke variabele langs met zo'n publiek voorvoegsel en vraag per stuk: waarom moet dit publiek zijn? Voor het meet-ID van je statistiekentool is dat logisch, voor iets met "secret" of "key" in de naam niet.
Wie is verantwoordelijk als er persoonsgegevens uitlekken?
Jij. Niet je bouwer, niet je hostingpartij en zeker niet de AI die de code schreef. In de AVG heet dat de verwerkingsverantwoordelijke: degene die bepaalt waarom en hoe gegevens worden verwerkt. Dat is de ondernemer, ook als hij geen regel code heeft aangeraakt.
De drempel voor persoonsgegevens ligt lager dan je denkt. Een naam met een e-mailadres uit een contactformulier telt al mee.
Zodra die gegevens toegankelijk waren voor iemand die er niet bij hoorde, is er sprake van een datalek. Dat meld je bij de Autoriteit Persoonsgegevens, in principe binnen 72 uur nadat je het ontdekt hebt. Alleen als het lek waarschijnlijk geen risico oplevert voor de betrokkenen mag je die melding achterwege laten. Is het risico juist groot, dan informeer je de mensen zelf ook.
Daarnaast verplicht de AVG je tot passende technische maatregelen, en de vijf punten hierboven vallen daaronder.
De Autoriteit deelt niet bij elk incident een boete uit. Maar het gesprek met je klanten over hun gelekte gegevens voer je liever niet, en daar zit meestal de echte schade.
Hoe voorkom je dit zonder zelf developer te worden?
Door de reviewlaag terug te zetten die uit het bouwproces is gevallen. Dat doen wij bij elke livegang, en het is minder werk dan het lijkt.
Voordat een site van ons live gaat, loopt hij langs een vaste lijst. Staan de security headers erin, met een CSP die past bij de scripts die er echt op staan? Zit er geen sleutel in de code die de browser binnenhaalt? Wordt elke actie die gegevens wijzigt op de server gecontroleerd? Zit de database op slot met regels per tabel? Na de livegang doen we die controles nog een keer op het echte domein, want een testomgeving staat anders ingesteld dan een echte site.
Geen van deze checks vraagt om anders bouwen. Ze vragen om iemand die weet waar hij moet kijken.
Zelf iets gebouwd en geen idee of dit goed zit? Stuur ons de URL, dan kijken we gratis naar wat van buitenaf zichtbaar is. Je krijgt een eerlijk antwoord, ook als dat antwoord is dat het prima in orde is.
Blijf vooral bouwen met AI. Zorg alleen dat er iemand meekijkt voordat het live gaat.
Veelgestelde vragen
Is een website die met AI is gebouwd onveilig?expand_more
Niet per definitie. AI genereert code die werkt, maar controleert niet of die code veilig is, omdat daar niet om gevraagd wordt. De code is precies zo veilig als de persoon die hem heeft nagekeken. Zonder review ontbreken meestal dezelfde vijf dingen: databasebeveiliging, filtering van formulierinvoer, security headers, controle op de server en het weghouden van API-sleutels uit de browser.
Hoe controleer ik zelf of mijn website security headers heeft?expand_more
Ga naar securityheaders.com, vul je eigen domein in en start de scan. Je krijgt een cijfer van A+ tot F en een overzicht van welke headers ontbreken. Dit is een passieve controle die niets aan je site verandert. Ontbreken HSTS, CSP en X-Content-Type-Options, dan zijn dat de eerste dingen om te laten toevoegen.
Wie is aansprakelijk als er via mijn website persoonsgegevens uitlekken?expand_more
De ondernemer. In de AVG ben jij de verwerkingsverantwoordelijke, want jij bepaalt waarom en hoe gegevens worden verwerkt. Je websitebouwer en je hostingpartij zijn verwerkers, en de AI die de code schreef is geen partij. Bij een datalek meld je dat in principe binnen 72 uur na ontdekking bij de Autoriteit Persoonsgegevens, tenzij het lek waarschijnlijk geen risico oplevert.
Kan iedereen zomaar bij de database van mijn website?expand_more
Dat kan als de beveiligingsregels in je database uitstaan. Bij opzetten waarbij de browser rechtstreeks met de database praat, zit er een publieke sleutel in je website en zijn regels per tabel de enige beveiligingslaag die er is. Staan die uit, dan kan iedereen die de sleutel uit je broncode haalt de hele tabel opvragen. In het dashboard van je databaseleverancier zie je per tabel of er regels actief zijn.
Meer over bouwen met AI-tools: hoe groot het risico op vendor lock-in echt is en wat je écht meekrijgt als je je site exporteert uit Lovable of Bolt. Over de meldplicht bij datalekken: Autoriteit Persoonsgegevens.