Broken Access Control: waarom verbroken toegangscontrole de nummer 1 blijft

Broken Access Control — verbroken toegangscontrole — staat in de OWASP Top 10 al sinds 2021 op nummer één, en ook in de editie 2025 is die positie onbetwist. In de webapplicatie-pentests die wij uitvoeren is het steevast de categorie die de meeste bevindingen oplevert, en vaak de zwaarste. De reden is even eenvoudig als hardnekkig: bijna elke applicatie regelt authenticatie (wie ben je?) wel netjes, maar autorisatie (wat mag je?) veel slordiger. En juist die tweede vraag bepaalt of gebruiker A bij de gegevens van gebruiker B kan.

Wat toegangscontrole precies is

Toegangscontrole is het geheel aan regels dat bepaalt welke handelingen een gebruiker mag uitvoeren en welke gegevens hij mag zien. Verbroken toegangscontrole ontstaat wanneer die regels ontbreken, verkeerd zijn geïmplementeerd of te omzeilen zijn. Het gaat bijna nooit om een gebruiker die zijn eigen wachtwoord kraakt; het gaat om een geauthenticeerde gebruiker die meer kan dan de bedoeling is, of om een buitenstaander die een functie bereikt die achter een login had moeten zitten.

Een cruciaal onderscheid is dat tussen horizontale en verticale escalatie. Bij horizontale escalatie benadert een gebruiker gegevens van een andere gebruiker op hetzelfde rechtenniveau — bijvoorbeeld de factuur, het dossier of het bericht van een andere klant. Bij verticale escalatie verkrijgt een gewone gebruiker rechten van een hoger niveau, zoals beheerdersfuncties. Beide zijn ernstig, maar verticale escalatie geeft een aanvaller vaak de sleutels tot het hele systeem.

Hoe wij het aanvallen tijdens een pentest

Broken access control is bij uitstek een categorie waar de handmatige expertise van de pentester het verschil maakt. Onze standaardaanpak begint met twee testaccounts met verschillende rechten, plus waar mogelijk een beheerdersaccount. Vervolgens proberen we systematisch of gebruiker A bij alles van gebruiker B kan.

De meest productieve aanvalslijn is de Insecure Direct Object Reference, oftewel IDOR. Veel applicaties tonen gegevens op basis van een identifier in de URL of in een API-verzoek, bijvoorbeeld /api/facturen/1042. Wij verhogen of verlagen dat nummer en kijken of de applicatie controleert of de opvragende gebruiker daadwerkelijk recht heeft op factuur 1043. Verrassend vaak is dat niet zo. Dezelfde logica passen we toe op UUID's, e-mailadressen en klantnummers die in verzoeken worden meegestuurd.

Een tweede lijn is forced browsing: we benaderen beheer-URL's, exportfuncties en API-endpoints rechtstreeks, zonder via de reguliere navigatie te gaan. Als /admin of /api/users/export bereikbaar is voor een gewone gebruiker, is er een verticaal escalatieprobleem. We letten daarbij scherp op verborgen of niet-gelinkte functionaliteit die wel bestaat maar onvoldoende is afgeschermd.

Een derde, subtielere lijn zijn manipuleerbare parameters die de rol of context bepalen. Denk aan een verborgen formulierveld role=user dat we naar role=admin veranderen, een cookie of JWT-claim die het rechtenniveau vastlegt, of een parameter die bepaalt namens welke organisatie een handeling wordt uitgevoerd. Ook methode-gebaseerde omzeilingen horen hier: een functie die via de knop in de interface netjes wordt gecontroleerd, maar bij een rechtstreeks HTTP-verzoek met een andere methode (bijvoorbeeld PUT in plaats van GET) de controle overslaat.

Sinds de OWASP Top 10:2025 valt ook Server-Side Request Forgery (SSRF) onder deze categorie. Bij SSRF misbruiken we de server om verzoeken te doen naar interne systemen of naar cloud-metadata-endpoints die van buitenaf onbereikbaar zouden moeten zijn. Het is in wezen toegangscontrole vanuit het perspectief van de server: de applicatie mag niet zomaar namens de aanvaller interne bronnen benaderen.

Waarom scanners deze categorie missen

Een geautomatiseerde vulnerability scan is uitstekend in het vinden van bekende kwetsbaarheden en verkeerde configuraties, maar vrijwel blind voor gebroken toegangscontrole. Een scanner weet immers niet dat factuur 1042 bij klant A hoort en factuur 1043 bij klant B; hij kent de bedoelde autorisatiematrix niet. Het herkennen van een IDOR vereist begrip van de business logic en van de vraag wie wát mag zien. Dit is precies waarom een pentest wezenlijk verschilt van een scan, en waarom deze categorie zonder handmatig onderzoek structureel onder de radar blijft.

Concrete impact

De gevolgen van broken access control zijn zelden theoretisch. In onze praktijk hebben deze bevindingen geleid tot inzage in klantdossiers van derden, tot het kunnen aanpassen van bestellingen en prijzen namens andere accounts, en tot toegang tot beheerfunctionaliteit vanuit een gewoon gebruikersaccount. Voor organisaties die persoonsgegevens verwerken, is een IDOR bovendien al snel een datalek in de zin van de AVG, met de bijbehorende meld- en documentatieplicht.

Hoe je het voorkomt

De belangrijkste ontwerpregel is deny by default: elke functie en elk gegeven is standaard afgeschermd, en toegang wordt alleen expliciet verleend. Controleer autorisatie altijd aan de serverzijde, bij elk verzoek, en vertrouw nooit op verborgen velden, uitgeschakelde knoppen of clientzijdige checks — die zijn triviaal te omzeilen.

Werk waar mogelijk met eigenaarschapscontroles in plaats van alleen rolcontroles. Het is niet genoeg om te controleren dat iemand de rol 'gebruiker' heeft; de applicatie moet controleren dat déze gebruiker eigenaar is van juist dit object. Centraliseer de autorisatielogica in één laag of component in plaats van de controles door de hele codebase te verspreiden, zodat ze consistent en toetsbaar zijn. Log toegangsfouten en waarschuw bij patronen die op systematisch aftasten wijzen. En neem toegangscontrole expliciet mee in de testcases: een goede geautomatiseerde testsuite bevat scenario's waarin gebruiker A bewust probeert bij de gegevens van gebruiker B te komen.

Van bevinding naar herstel en retest

Wanneer wij broken access control aantreffen, beschrijven we per bevinding niet alleen de kwetsbaarheid, maar ook de exploiteerbaarheid en de concrete impact — welke gegevens of functies bereikbaar waren en voor wie. Het hersteladvies richt zich op de onderliggende oorzaak, niet op het dichttimmeren van één URL. Omdat toegangscontroleproblemen vaak structureel zijn, adviseren we doorgaans een controle van vergelijkbare endpoints in de hele applicatie. Na het herstel volgt een gerichte retest: pas als verifieerbaar is dat de omzeiling niet meer werkt én dat de fix niet elders is vergeten, beschouwen we de bevinding als gesloten.

Secure Audit voert webapplicatie-pentests uit waarin geautomatiseerde tooling en handmatig onderzoek worden gecombineerd, met bijzondere aandacht voor autorisatie en business logic. Neem contact op voor een vrijblijvend gesprek over de scope van een pentest voor jouw applicatie.