Een app die werkt, is niet automatisch een app die veilig is
Met AI-tools kunt u tegenwoordig verrassend snel een klantenportaal, dashboard of planningsoverzicht maken. Ook kleine ondernemers kunnen daardoor software laten bouwen die vroeger buiten hun budget viel. Dat is een echte vooruitgang. Maar een werkende knop laat nog niet zien of de server bij elke aanvraag de juiste rechten controleert.
Voor een persoonlijke takenlijst is dat risico anders dan voor een applicatie met klantdossiers, adressen, personeelsgegevens of factuurbedragen. Het moment waarop echte bedrijfsgegevens worden toegevoegd, is daarom een logisch moment om de technische basis grondig te beoordelen.
De belangrijkste eerste vraag
Kan gebruiker A gegevens van gebruiker B zien of wijzigen? Niet alleen via het menu, maar ook via de server, database en directe URL's. Een verborgen knop is geen beveiliging. Toegangscontrole moet aan de achterkant worden afgedwongen.
Dit is ook het eerste risico in de OWASP Top 10:2025.
Zes controles vóórdat uw AI-app live gaat
Dit is geen lijstje dat u blind hoeft af te vinken. Het zijn vragen die helpen ontdekken of uw applicatie klaar is voor werkelijk gebruik.
1. Toegang tot gegevens
Kan medewerker A alleen de klanten en dossiers zien die bij zijn rol horen? Controleer dit met twee aparte testaccounts, ook wanneer iemand rechtstreeks een link naar een dossier opent.
2. Database en Supabase RLS
Een ingelogde gebruiker is niet automatisch bevoegd om alle rijen te lezen. Controleer Row Level Security, databasegrants en het onderscheid tussen openbare en beheerdersfuncties.
3. Geheimen en sleutels
API-tokens en databasegeheimen horen niet in browsercode of openbare repositories. Controleer omgevingvariabelen, serverfuncties, permissies en wat er gebeurt als een sleutel moet worden vervangen.
4. Invoer, uploads en koppelingen
Controleer wat de app doet met onverwachte invoer, bestandsuploads, dubbele opdrachten, foutieve antwoorden van externe systemen en herhaalde webhooks.
5. Pakketten en hosting
Beoordeel afhankelijkheden, bekende kwetsbaarheden, toegang tot GitHub en hosting, en wie wijzigingen naar productie mag publiceren.
6. Logging, back-up en herstel
Hoe merk je dat een koppeling uitvalt? Wat wordt gelogd zonder gevoelige gegevens bloot te leggen? En is een back-up ook daadwerkelijk terug te zetten?
Supabase-gebruikersrechten: een herkenbaar voorbeeld
Stel: u heeft een app gebouwd waarin klanten hun eigen opdrachten kunnen bekijken. De inlogfunctie werkt uitstekend. Maar als de database niet goed is afgeschermd, kan een gewone gebruiker mogelijk ook opdrachten van een ander account opvragen. Dat voorkomt u niet door de knop ‘Andere klanten’ uit het menu te verwijderen.
Bij Supabase zijn databasegrants en Row Level Security (RLS) belangrijk: zij bepalen welke gegevens de ingelogde gebruiker via de database-API mag benaderen. Een servergeheim met verhoogde rechten heeft een andere functie dan een publieke sleutel die in de browser mag staan. Beide verwarren kan ernstige gevolgen hebben.
Test daarom met eigen testdata en twee geautoriseerde testaccounts. Controleer niet alleen of elke gebruiker zijn eigen dossier ziet, maar ook of een ongeoorloofde lees-, wijzig- of verwijderactie wordt geblokkeerd. Leg het resultaat vast.
En securityheaders, HTTPS en een online scan dan?
Die doen ertoe, maar ze beantwoorden een andere vraag. HTTPS beschermt de verbinding. Headers als Content-Security-Policy en HSTS helpen bij specifieke browserrisico's. Een externe scanner kan ontbrekende instellingen signaleren.
Een goede headerscore betekent niet dat uw applicatie veilig met klantgegevens omgaat.De scanner weet meestal niet wie uw gebruikers zijn, welke dossiers ze mogen zien, of uw databasepolicies kloppen en of financiële opdrachten dubbel verwerkt kunnen worden.
Gebruik zo'n controle dus als één onderdeel van de technische beoordeling, niet als bewijs dat de volledige code, autorisatie of bedrijfslogica veilig is.
Wat moet u aan de ontwikkelaar of AI-bouwer vragen?
- Wie kan bij de broncode, database en hosting? En wat gebeurt er als de oorspronkelijke bouwer wegvalt?
- Zijn rollen en rechten ook op de server gecontroleerd? Vraag om testresultaten met verschillende accounts.
- Zijn externe koppelingen beheersbaar? Denk aan verlopen tokens, dubbele verwerking en tijdelijk onbereikbare systemen.
- Wie verwerkt beveiligingsupdates? Denk aan gebruikte bibliotheken, frameworks en hostingconfiguratie.
- Kan de app worden hersteld? Vraag om back-upafspraken en ten minste een beschreven herstelroute.
Laat wijzigingen beoordelen vóór de applicatie toegang krijgt tot productiegegevens. Bij gevoelige of bedrijfskritische toepassingen kan een gespecialiseerde applicatiepentest nodig zijn, naast een gewone code- en configuratiebeoordeling.
AI mag bouwen. U blijft verantwoordelijk voor de bedrijfsgegevens.
De vraag is niet of ChatGPT, Claude of Lovable de code heeft geschreven. Ook handgeschreven software bevat fouten. De vraag is of iemand het ontwerp, de rechten, de gegevensstromen en het herstel aantoonbaar heeft getest.
InstantIT helpt zakelijke IT-omgevingen, Microsoft 365 en technische softwarekoppelingen in kaart brengen. Bij een bestaande applicatie bespreken we eerst de concrete vraag en de benodigde toegang. Voor diepgaande offensieve beveiligingstests hoort een gespecialiseerde pentester bij het traject.
Veelgestelde vragen
Is een app die met AI gemaakt is onveilig?
Niet per definitie. De gebruikte tool zegt weinig over de beveiligingskwaliteit. Toegang, dataopslag, code en daadwerkelijk uitgevoerde tests zijn belangrijker.
Is een SSL-certificaat genoeg?
Nee. Het beschermt de verbinding, maar zegt niets over wie gegevens kan inzien, aanpassen of verwijderen.
Hoe controleer ik of mijn Supabase-app veilig is?
Begin met databasegrants, RLS-beleid, toegang tot geheimen en de toegangsrechten van verschillende testaccounts. Controleer vervolgens logs, API-routes en herstel.