Is je met AI gebouwde website of app veilig? Checklist

AI-tools optimaliseren voor iets wat werkt en er goed uitziet. Beveiliging is onzichtbaar: een app zonder toegangsregels werkt precies hetzelfde als een app met toegangsregels, totdat iemand de gegevens van een ander opvraagt.

Daar komt bij dat veel mensen die met AI bouwen geen developer zijn, en dus niet weten waar ze op moeten letten. Lovable heeft ingebouwde scans die onder meer databasetoegang, Row Level Security, afhankelijkheden en gelekte sleutels controleren. Lovable schrijft er zelf bij dat die scans geen grondige security review vervangen, geen volledige beveiliging garanderen en dat jij verantwoordelijk bent voor de beveiliging van je app.

Controleer dit als eerste: elke sleutel die in de browsercode staat, kan iedereen zien. Open je site, druk op F12 en zoek in de broncode of het netwerktabblad naar woorden als key, secret of token.

Niet elke sleutel is geheim. Supabase onderscheidt een publishable key (vroeger anon key), die in een webpagina mag staan, en een secret key (of service_role key). Die laatste omzeilt volgens Supabase elke Row Level Security-policy en mag nooit in een browser, een uitgeleverde app of in versiebeheer terechtkomen. Hetzelfde geldt voor sleutels van betaalproviders, e-maildiensten en AI-API's zoals die van OpenAI: die horen op de server, bijvoorbeeld in een Edge Function of API-route.

Row Level Security (RLS) moet aan staan op elke tabel in een openbaar schema, met policies die bepalen wie welke rijen mag lezen en wijzigen. Zonder RLS is een tabel volgens Supabase leesbaar en schrijfbaar voor elke rol die er rechten op heeft, dus ook voor anonieme bezoekers met de publishable key.

RLS voegt als het ware een WHERE-regel toe aan elke query. Een veelgebruikte policy is: een gebruiker mag alleen rijen zien waarvan de user_id gelijk is aan zijn eigen id. Let op policies die RLS wel aanzetten maar alles toestaan, zoals een regel die altijd true teruggeeft. Dan staat RLS aan, maar beschermt het niets.

Gebruik een bewezen authenticatiedienst en bouw login nooit zelf. Supabase Auth, Clerk of Auth.js regelen wachtwoordopslag, sessies en e-mailverificatie beter dan zelfgeschreven code.

Controleer daarnaast of beveiligde pagina's echt op de server worden afgeschermd. Een pagina die alleen in de frontend wordt verborgen voor niet-ingelogde bezoekers, is niet beveiligd: de data eronder moet ook via RLS of een servercontrole zijn afgeschermd. Zet e-mailbevestiging aan en overweeg tweestapsverificatie voor beheerders.

Alles wat een bezoeker invult, moet op de server worden gecontroleerd. Controle in de browser is handig voor de gebruiker, maar een aanvaller stuurt verzoeken rechtstreeks naar je API.

Controleer op type, lengte en toegestane waarden, bijvoorbeeld met een schemavalidatie zoals Zod. Voeg bij openbare formulieren een vorm van spambescherming en rate limiting toe, anders kan iemand je database of mailbox volspammen of je AI-tegoed opmaken.

Verzamel je persoonsgegevens, bijvoorbeeld via een contactformulier, account of nieuwsbrief, dan gelden de regels van de AVG. Je hebt dan onder meer een privacyverklaring nodig en je verwerkt niet meer gegevens dan nodig.

Voor functionele cookies heb je volgens de Autoriteit Persoonsgegevens geen toestemming nodig, wel voor tracking cookies. Die toestemming moet actief worden gegeven; verder scrollen telt niet, standaard aangevinkte vakjes mogen niet en een cookiewall is onder de AVG verboden. Let ook op waar je data staat: kies bij Supabase en je hosting bij voorkeur een regio in de EU en sluit waar nodig een verwerkersovereenkomst af.

Zorg dat je zowel je code als je database kunt terugzetten. Code staat veilig als je project gekoppeld is aan GitHub; je database heeft aparte back-ups nodig.

Controleer welke back-ups je hostingpakket of databaseplan maakt, hoe lang ze bewaard blijven en of je ooit hebt getest of terugzetten werkt. Een back-up die je nooit hebt teruggezet, is een aanname.

Een AI-app bestaat uit tientallen tot honderden open-sourcepakketten, en daarin worden regelmatig kwetsbaarheden gevonden. Iemand moet die bijwerken.

Zet op GitHub meldingen voor kwetsbare afhankelijkheden aan (Dependabot) of laat de scans van je tool regelmatig draaien. Plan updates in, test daarna en houd bij wat er is veranderd. Meer over doorlopend onderhoud lees je in website-onderhoud en beveiliging.

Laat een tweede paar ogen kijken voordat je klanten of hun gegevens aan je app toevertrouwt. Een review kost minder dan het oplossen van een datalek.

Bij Easybrand controleren we AI-projecten uit Lovable, Bolt, v0 en vergelijkbare tools op sleutels, RLS, login, invoercontrole en AVG-basis. Een check kost vanaf € 149; daarna kun je het prototype professioneel laten afmaken. Voor complexere apps en portalen kijk je bij software op maat.