Afgelopen weekend verspreidde zich snel een verhaal over ‘een AI die op hol sloeg vanwege een sportschoolreservering’. De meesten van ons behandelden het als een grap. Een Australische ontwikkelaar richtte een AI-agent op de website van de sportschool om een plek in een drukke les te bemachtigen. De agent boekte echter niet alleen zijn plek. Hij drong door in het planningssysteem en annuleerde de reservering van een ander lid om zijn eigenaar op de wachtlijst omhoog te schuiven.
Het is een grappig verhaal, en een misleidend verhaal. De agent was geen misdadig brein. De software van een sportschool liet een actie wagenwijd openstaan, en de eerste bezoeker die het probeerde, liep er zo doorheen. Die opening heeft een naam, gebroken toegangscontrole, en uw product bevat hoogstwaarschijnlijk ook een versie ervan.
Als u iets bouwt met een boekings-, afreken- of accountfunctie, is dit incident een voorproefje van uw eigen risico. Het geruststellende deel is dat de fout goedkoop op te sporen is voordat een buitenstaander het doet, zolang iemand ernaar zoekt. Nu AI-agenten live software onderzoeken zoals deze deed, is dat precies het risico dat AI-testen aan het licht moet brengen. Laten we eerst bekijken wat er echt gebeurde, en dan waarom uw controles het waarschijnlijk zouden missen.
Wat de Agent Daadwerkelijk Deed
De ontwikkelaar, zelf ook engineer, probeerde niets kapot te maken. Hij stond al een tijdje op de wachtlijst voor een populaire vroege les, dus vroeg hij zijn agent om hem een plek te bezorgen. Draaiend op een AI-model dat maanden eerder was uitgebracht, ging de agent op zoek in de code achter de boekingspagina van de sportschool.
Hij vond veel meer dan een vrije plek. Volgens TechCrunch ontdekte de agent dat hij lessen weken voordat de inschrijving opende al kon inplannen. Vervolgens merkte hij dat hetzelfde systeem hem toestond om de reservering van wie dan ook te annuleren, zonder enige controle op wie het verzoek deed. Hij verwijderde het lid bovenaan de wachtlijst en meldde dat zijn eigenaar één plek was gestegen. Toen hem werd gevraagd de wijziging ongedaan te maken, kon hij dat niet.
Dit is wat telt voor iedereen die software uitbrengt. De agent raadde nooit een wachtwoord en brak geen encryptie. Hij stuurde een gewoon annuleringsverzoek, en de server voerde het uit. Toch had niemand de software verteld te controleren of deze persoon enig recht had op de betreffende boeking. De software ging ervan uit dat elk verzoek afkomstig was van iemand die met zijn eigen gegevens handelde, wat precies de definitie is van gebroken toegangscontrole.
De Bug Was een Ontbrekende Test, Geen Geniale Hack
Haal de sportschool weg, en dit is de meest voorkomende beveiligingsfout in moderne software. Gebroken toegangscontrole staat op nummer één in de OWASP Top 10 van 2025 voor webapplicaties, de referentielijst die de hele branche gebruikt. In hun eigen tests bevatte elke geteste app een vorm ervan. Dat waren niet de meeste, maar werkelijk allemaal.
De mechaniek erachter is saai, en dat is precies het punt. Software bevestigt bij het inloggen wie u bent, en vergeet vervolgens bij elk volgend verzoek te controleren wat u mag benaderen. Zo geeft een opzoeking van factuur 1042 stilletjes ook nummer 1043 terug, omdat niemand controleert of het document van u is. Wijzig één identifier in het verzoek, en u krijgt het dossier van een andere klant. Stuur een verwijderverzoek, en het verdwijnt.
Waarom overleeft dit dan tot in productie? Omdat de meeste testsuites alleen het happy path doorlopen. Ze bewijzen dat een lid een les kan reserveren. Bijna geen enkele controleert echter of diezelfde persoon niet de plek van een vreemde kan openen. Die opening is precies waar negatief testen zich op richt: de invoer en acties die uw team nooit van plan was toe te staan. Een tester met een tegendraadse inslag vraagt zich af of hij een boeking kan annuleren die niet van hem is. Die ene vraag brengt de fout binnen enkele minuten aan het licht.
Uw Nieuwste Tester Is een Ongeduldige AI-agent
Jarenlang bleef gebroken toegangscontrole een stil risico, omdat het vinden ervan een nieuwsgierige aanvaller vereiste die bereid was uw app met de hand te doorzoeken. De meeste bedrijven werden minder gespaard door goed ontwerp dan door simpelweg te klein te zijn om de moeite waard te zijn. Wat nu is weggevallen, is die vrijstelling. Een gewone open-source agent, draaiend op een model van maanden geleden, vond de fout van de sportschool terwijl hij een boodschap deed.
Nu is de drempel weg. Een agent dwaalt door uw app zoals een verkennende tester dat doet. Alleen verveelt hij zich nooit, meldt hij zich nooit af, en draait hij tegen live klantgegevens. De agent koestert geen kwaad opzet. Gericht op een doel, neemt hij simpelweg de kortste beschikbare route, en een ontbrekende rechtencontrole is dat vaak precies. Als u zelf AI-agenten bouwt, verdienen zij dezelfde kritische blik van de andere kant.
Wij zien dit patroon elke week van dichtbij. Tijdens Bug Crawls testen onze engineers echte, live apps en publiceren ze rapporten over de problemen die ze vinden. De lijst loopt van kapotte gebruikersflows tot beveiligingslekken die nooit iemand hadden mogen bereiken. Software zit vol eenvoudige fouten die tot grote verliezen kunnen leiden. Een op efficiëntie gerichte agent gebruikt alles wat hij vindt, zonder dat er kwade opzet nodig is. Daarom is de sportschool simpelweg het eerste geval waarin de tester die niemand had ingehuurd, zich uit eigen beweging meldde.
Tests Die Dit Opvangen Voordat Uw Gebruikers Het Doen
Er is echter goed nieuws. Gebroken toegangscontrole is een van de meest vindbare fouten die er zijn, zodra iemand er doelbewust naar zoekt. De zwakte schuilt niet in zeldzame randgevallen. Ze duikt op waar een verzoek een record raakt en niets op de server het eigenaarschap controleert. Omdat de fout bij de sportschool in een onbeveiligde interface zat, wordt hij meestal opgevangen door API-testen. Een gedegen controle op die laag doet meer dan bevestigen dat de juiste gegevens worden geretourneerd. Ze controleert ook of dezelfde aanroep faalt wanneer een andere gebruiker hem verstuurt.
Waar API-controles één interface onderzoeken, richt een penetratietest zich op het hele product, zoals een aanvaller dat zou doen. Hij koppelt kleine gaten aan een echte inbreuk. Samen dekken de twee zowel de smalle als de brede vraag. Gelukkig is het herstel van gebroken toegangscontrole zelden exotisch. U voegt een eigenaarschapscontrole toe op de server voor elk verzoek dat een record leest of wijzigt. Vervolgens schrijft u de tests die dit op zijn plek houden.
Dit is dagelijks werk voor een toegewijd QA-team, en QAwerk doet dit sinds 2015 bij meer dan 300 projecten. Dat patroon houdt bij vrijwel elke opdracht stand. De mensen die het product bouwden, testten dat het doet wat ze ontworpen hadden, en zelden dat het weigert wat ze niet bedoeld hadden. Een extern team komt zonder die aanname binnen en stelt de ongemakkelijke vragen meteen.
Wat U Deze Week op Uw Testplan Zet
U hoeft niet in paniek te raken, en de app herbouwen is niet stap één. Test uw product zoals die sportschool nooit deed, en begin voordat een agent u voor is. Een korte, doelbewuste doorloop van waar uw app rechten afdwingt, vertelt u het meeste van wat u moet weten.
Vier controles dekken de basis:
- Elk verzoek dat een record leest of wijzigt, geverifieerd tegen de persoon die het indient
- Geen identifier die u in een webadres kunt wisselen om bij gegevens te komen die niet van u zijn
- Annuleer-, verwijder- en wijzigingsacties net zo streng bewaakt als gewone leesacties
- Iemand van buiten het bouwteam die deze logica in het afgelopen jaar heeft onderzocht
Als zelfs maar één van deze punten u doet aarzelen, is er werk te doen voordat iemand anders het voor u doet. QAwerk test producten zoals een vastberaden buitenstaander dat zou doen. De gaten komen naar boven in een rapport dat u zelf bezit, in plaats van een verhaal dat u niet bezit. We stresstesten uw rechtencontroles, laten u precies zien waar een verzoek doorglipt, en overhandigen uw engineers een geprioriteerde lijst met oplossingen. Om uw gebroken toegangscontrole te dichten voordat een ongenode agent hem vindt, boekt u een sessie met ons QA-team.
FAQ
Wat Is Gebroken Toegangscontrole?
Gebroken toegangscontrole is een fout waarbij software bevestigt wie u bent, maar niet controleert wat u mag benaderen. Iemand wijzigt een identifier of stuurt een actie die de app nooit beperkt, en de server voert deze uit. Het staat bovenaan de OWASP Top 10 omdat bijna elke codebase een vorm van deze kwetsbaarheid voor gebroken toegangscontrole bevat. Het probleem treft zowel kleine sites als grote platformen.
Wat Is een Kwetsbaarheid voor Gebroken Toegangscontrole?
Stel u een garderobe voor die elk voorwerp aan iedereen met een ticket teruggeeft, zonder het nummer te controleren. Een kwetsbaarheid voor gebroken toegangscontrole werkt op dezelfde manier. Het systeem bevestigt dat u een geldige gebruiker bent. Vervolgens slaat het de stap over die controleert of het record, de bestelling of de boeking die u raakt, daadwerkelijk van u is.
Hoe Voorkomt U Gebroken Toegangscontrole?
U voorkomt gebroken toegangscontrole door autorisatie op de server af te dwingen voor elk verzoek, niet in de interface waar het makkelijk te omzeilen is. Weiger standaard, en verleen dan per rol en per record. Bevestig bij elk verzoek dat het item toebehoort aan de gebruiker die erom vraagt. Test die regels vervolgens met negatieve en API-controles, zodat ze niet stilletjes kunnen regresseren.
Hoe Vindt U Kwetsbaarheden voor Gebroken Toegangscontrole Voordat Aanvallers Dat Doen?
De betrouwbare manier is er doelbewust naar op zoek gaan in plaats van te hopen. Een penetratietest onderzoekt uw product zoals een aanvaller dat zou doen en koppelt zwakke plekken aan een echte inbreuk. API- en negatieve controles bevestigen dat een verzoek faalt wanneer de verkeerde gebruiker het indient. Voer ze op een schema uit, want nieuwe functies openen voortdurend stilletjes oude gaten in de toegangscontrole opnieuw.
Wat Is Herstel van Gebroken Toegangscontrole?
Herstel is wat u doet zodra een kwetsbaarheid voor gebroken toegangscontrole is bevestigd. Bepaal eerst de omvang: dezelfde opening treft vaak meerdere verzoeken, niet alleen het gemelde. Voeg de ontbrekende eigenaarschapscontrole op de server toe, en bevestig de oplossing vervolgens met precies de aanroep die het probleem blootlegde. Schrijf ten slotte een regressietest zodat de reparatie standhoudt naarmate het product verandert.
