Afgelopen weekend ging het verhaal over ‘een AI die op hol sloeg bij een sportschoolboeking’ razendsnel rond. De meesten van ons vonden het maar een grap. Een Australische ontwikkelaar had een AI-agent ingezet om via de website van de sportschool een plekje te bemachtigen in een populaire les. De AI boekte echter niet alleen zijn plek, maar greep ook in het reserveringssysteem en annuleerde de reservering van een ander lid, waardoor de eigenaar hoger op de wachtlijst kwam te staan.
Het is een grappig verhaal, maar ook een misleidend verhaal. De agent was geen crimineel genie. De software van een sportschool liet een bepaalde handeling volledig onbeveiligd, en de eerste bezoeker die het probeerde, liep er dwars doorheen. Zo’n lek heeft een naam: gebroken toegangscontrole, en de kans is groot dat uw product een variant daarvan bevat.
Als je iets bouwt met een boekings-, afreken- of accountfunctie, is dit incident een voorproefje van je eigen risico. Het geruststellende is dat de fout goedkoop te vinden is voordat een buitenstaander dat doet, zolang er maar iemand naar zoekt. Nu AI-agenten live software op deze manier testen, is dat precies het risico dat AI-testen aan het licht moeten brengen. Laten we eerst eens kijken wat er precies is gebeurd en waarom je controles dit waarschijnlijk zouden missen.
Wat de agent daadwerkelijk deed
De ontwikkelaar, zelf ingenieur, probeerde niets kapot te maken. Hij stond al een tijdje op de wachtlijst voor een populaire vroege les, dus vroeg hij zijn agent om een plekje voor hem te regelen. Met behulp van een AI-model dat enkele maanden eerder was uitgebracht, ging het model de code van de boekingspagina van de sportschool doorzoeken.
Het systeem vond veel meer dan alleen een vrije plek. Volgens TechCrunch ontdekte de agent dat het weken voor de inschrijving al lessen kon inplannen. Vervolgens merkte het systeem dat het iedereen toestond een reservering te annuleren, zonder te controleren wie de annulering aanvroeg. Het verwijderde het lid bovenaan de wachtlijst en meldde dat de eigenaar één plek was opgeschoven. Toen er werd gevraagd de wijziging ongedaan te maken, bleek dat niet mogelijk.
Dit is wat belangrijk is voor iedereen die software levert. De agent heeft nooit een wachtwoord geraden of de encryptie gekraakt. Er werd een gewoon annuleringsverzoek verzonden en de server heeft dat verwerkt. Maar niemand had de software opdracht gegeven om te controleren of deze persoon recht had op de betreffende boeking. De software ging ervan uit dat elk verzoek afkomstig was van iemand die handelde op basis van zijn eigen gegevens, wat de definitie is van een gebrekkige toegangscontrole.
De bug was een ontbrekende test, geen geniale truc
Zonder de sportschool is dit de meest voorkomende beveiligingsfout in moderne software. Een gebrekkige toegangscontrole staat bovenaan de OWASP Top 10 van 2025 voor webapplicaties, de referentielijst die de hele branche gebruikt. Tijdens hun eigen tests bleek elke app die ze beoordeelden een of andere vorm van dit probleem te hebben. En niet slechts de meeste, maar stuk voor stuk.
De werking is saai, en dat is precies de bedoeling. De software bevestigt je identiteit bij het inloggen, maar vergeet vervolgens bij elke volgende aanvraag te controleren tot welke gegevens je toegang hebt. Zo krijg je bij een zoekopdracht naar factuur 1042 stilletjes nummer 1043 te zien, omdat niemand controleert of het document wel van jou is. Wijzig je één identificatiecode in de aanvraag, dan krijg je het record van een andere klant. Verstuur je een verwijderingsverzoek, dan verdwijnt het.
Waarom komt dit dan toch in productie terecht? Omdat de meeste testsuites alleen het ‘happy path’ testen. Ze bewijzen dat een lid een les kan reserveren. Bijna geen enkele testsuite controleert echter of diezelfde persoon niet de plek van een onbekende kan overnemen. Die lacune is precies waar negatieve testen zich op richten: de invoer en acties die je team nooit had willen toestaan. Een tester met een kritische inslag vraagt of hij een boeking kan annuleren die niet van hem is. Die ene vraag legt de fout binnen enkele minuten bloot.
Je nieuwste tester is een ongeduldige AI-agent
Jarenlang bleef een gebrekkige toegangscontrole een stil risico, omdat het alleen te vinden was door een nieuwsgierige aanvaller die bereid was je app handmatig te manipuleren. De meeste bedrijven werden er niet door getroffen dankzij een goed ontwerp, maar eerder doordat ze te klein waren om zich er druk over te maken. Wat nu is weggevallen, is die vrijbrief. Een gewone open-source agent, die een model van enkele maanden geleden gebruikte, ontdekte de kwetsbaarheid van de sportschool tijdens een simpele boodschap.
Nu is de barrière verdwenen. Een agent dwaalt door je app zoals een verkennende tester dat doet. Hij verveelt zich nooit, geeft geen goedkeuring en werkt met live klantgegevens. De agent heeft geen kwade bedoelingen. Gericht op een doel, neemt hij simpelweg de kortste route, en een ontbrekende toestemmingscontrole is vaak precies dat. Als je zelf AI-agents bouwt, moeten die aan dezelfde strenge controle van de andere kant worden onderworpen.
We volgen dit patroon elke week op de voet. Tijdens bugcrawls testen onze engineers echte, uitgebrachte apps en publiceren ze rapporten over de problemen die ze vinden. De lijst loopt van gebroken gebruikersflows tot beveiligingslekken die nooit iemand hadden mogen bereiken. Software zit vol met simpele fouten die tot grote verliezen kunnen leiden. Een efficiëntiegerichte agent gebruikt alles wat hij vindt, zonder kwade bedoelingen. De sportschool is dus simpelweg het eerste voorbeeld waar de tester die niemand had ingehuurd, uit zichzelf opdook.
Tests die dit detecteren voordat uw gebruikers het doen
Er is echter ook goed nieuws. Een gebrekkige toegangscontrole is een van de meest gemakkelijk te vinden kwetsbaarheden, zodra iemand er specifiek naar zoekt. De zwakte schuilt niet in zeldzame uitzonderingen. Het komt overal aan het licht waar een verzoek een record betreft en er op de server niets is dat het eigendom bevestigt. Omdat de kwetsbaarheid in de sportschool zich in een onbeveiligde interface bevond, wordt deze meestal ontdekt tijdens API-testen. Een grondige controle op dat niveau bevestigt niet alleen dat de juiste gegevens worden geretourneerd, maar verifieert ook dat dezelfde aanroep mislukt wanneer een andere gebruiker deze verstuurt.
Waar API-tests één interface onderzoeken, richt een penetratietest zich op het hele product, zoals een aanvaller dat zou doen. Het koppelt kleine hiaten aan elkaar tot een daadwerkelijke inbreuk. Met beide methoden dek je zowel de specifieke als de bredere vraag. Gelukkig is de oplossing voor gebroken toegangscontrole zelden ingewikkeld. Je voegt een eigenaarschapscontrole toe aan de server voor elk verzoek dat een record leest of wijzigt. Vervolgens schrijf je de tests die ervoor zorgen dat deze controle blijft werken.
Dit is dagelijkse kost voor een toegewijd QA-team, en QAwerk doet dit al sinds 2015 voor meer dan 300 projecten. Dat patroon is vrijwel bij elk project hetzelfde. De mensen die het product hebben ontwikkeld, hebben getest of het doet wat ze ontworpen hebben, en zelden of het weigert wat ze niet ontworpen hadden. Een extern team komt zonder die aannames en stelt de ongemakkelijke vragen direct.
Wat je deze week op je toetsplanning moet zetten
Je hoeft niet in paniek te raken, en het opnieuw opbouwen van de app is niet de eerste stap. Test je product op een manier die de sportschool nooit heeft gedaan, en begin ermee voordat een medewerker je voor is. Een korte, gerichte controle van de plekken in je app waar je toestemmingen vraagt, vertelt je al het meeste wat je nodig hebt.
Vier controles dekken de essentie:
- Elk verzoek waarmee een record wordt gelezen of gewijzigd, wordt geverifieerd door de persoon die het verzoek indient
- Er bestaat geen identificatiecode die je in een webadres kunt vervangen om toegang te krijgen tot gegevens die niet van jou zijn
- Annuleren, verwijderen en bijwerken worden net zo streng beveiligd als gewone leesbewerkingen
- Iemand van buiten het bouwteam heeft deze logica het afgelopen jaar onderzocht
Als ook maar één van deze punten je doet twijfelen, is er werk aan de winkel voordat iemand anders het voor je doet. QAwerk test producten zoals een doorgewinterde buitenstaander dat zou doen. De tekortkomingen komen aan het licht in een rapport waar jij verantwoordelijk voor bent, in plaats van in een verhaal waar jij geen verantwoordelijkheid voor draagt. We testen je toegangsrechten grondig, laten je precies zien waar een verzoek door de mazen van het net glipt en geven je engineers een lijst met prioriteiten voor de oplossingen. Om je gebrekkige toegangscontrole te dichten voordat een ongewenste gebruiker erachter komt, boek je een sessie met ons QA-team.
FAQ
Wat is een gebrekkige toegangscontrole?
Een gebrekkige toegangscontrole is een kwetsbaarheid waarbij software wel bevestigt wie je bent, maar niet controleert tot welke onderdelen je toegang hebt. Iemand wijzigt een identificatiecode of voert een actie uit die de app nooit blokkeert, en de server accepteert dit. Het staat bovenaan de OWASP Top 10 omdat bijna elke codebase een variant van deze kwetsbaarheid voor gebrekkige toegangscontrole bevat. Het probleem treft zowel kleine websites als grote platformen.
Wat is een kwetsbaarheid in de toegangscontrole?
Stel je een garderobe voor die elk item teruggeeft aan iedereen met een ticket, ongeacht of het nummer overeenkomt. Een beveiligingslek in de toegangscontrole werkt op dezelfde manier. Het systeem bevestigt dat je een geldige gebruiker bent. Vervolgens slaat het de stap over die controleert welk record, welke bestelling of welke boeking je aanraakt daadwerkelijk van jou is.
Hoe voorkom je dat toegangscontrole wordt omzeild?
Je voorkomt misbruik van toegangscontrole door autorisatie af te dwingen op de server voor elk verzoek, en niet in de interface waar het gemakkelijk te omzeilen is. Weiger standaard toegang en verleen vervolgens toegang per rol en per record. Controleer bij elk verzoek of het item daadwerkelijk van de gebruiker is die het verzoek indient. Test deze regels vervolgens met negatieve controles en API-controles, zodat ze niet ongemerkt kunnen terugvallen in oude functionaliteit.
Hoe vind je kwetsbaarheden in toegangscontrole voordat aanvallers dat doen?
De meest betrouwbare manier is om doelgericht te zoeken in plaats van te hopen. Een penetratietest onderzoekt uw product als een aanvaller en legt verbanden tussen zwakke plekken en een daadwerkelijke inbreuk. API- en negatieve controles bevestigen dat een verzoek mislukt wanneer de verkeerde gebruiker het indient. Voer ze volgens een vast schema uit, want nieuwe functies openen voortdurend ongemerkt oude, gebrekkige toegangscontrolelekken.
Wat houdt het herstellen van defecte toegangscontrole in?
Herstelmaatregelen zijn nodig zodra een kwetsbaarheid in de toegangscontrole is vastgesteld. Bepaal eerst de omvang van het probleem: dezelfde kwetsbaarheid treft vaak meerdere verzoeken, niet alleen het gemelde verzoek. Voeg de ontbrekende controle op servereigendom toe en bevestig de oplossing vervolgens met de exacte aanroep die het probleem aan het licht bracht. Schrijf ten slotte een regressietest om te controleren of de oplossing standhoudt bij productwijzigingen.
