API-security testen: de OWASP API Security Top 10 en de aanpak van een API-pentest

Waar een gebruiker vroeger via een webpagina met een applicatie communiceerde, verloopt het verkeer nu grotendeels via APIs: de koppelingen waarmee mobiele apps, single-page-applicaties, partners en interne systemen data uitwisselen. Die verschuiving heeft de manier veranderd waarop applicaties worden aangevallen. Een moderne webapplicatie is vaak niet meer dan een schil rond een verzameling API-endpoints, en juist daar zit tegenwoordig het grootste deel van de kwetsbaarheden. Toch zien we dat organisaties bij het uitvragen van een pentest nog vaak denken aan het testen van de zichtbare webinterface, terwijl de onderliggende API buiten scope blijft. Dat is een gemiste kans, want een aanvaller richt zich zelden op de knoppen die u ziet en vrijwel altijd op het verkeer eronder.

Waarom een API-pentest andere aandacht vraagt

Bij een klassieke webapplicatietest kijkt de tester vooral naar wat de applicatie via de browser aanbiedt. Bij een API ontbreekt die visuele context. Er is geen menu dat verraadt welke functies bestaan en geen scherm dat aangeeft welke velden een gebruiker mag zien. Een API-endpoint accepteert een gestructureerd verzoek en geeft een gestructureerd antwoord, en de beveiliging moet volledig aan de serverzijde worden afgedwongen. Precies daar gaat het mis: ontwikkelaars vertrouwen soms op de aanname dat alleen de eigen frontend de API aanroept, terwijl een aanvaller die aanname niet respecteert. Hij praat rechtstreeks met de API, manipuleert elk veld, verzint endpoints die niet in de documentatie staan en probeert precies die verzoeken die de frontend nooit zou versturen.

De OWASP API Security Top 10

Voor API-beveiliging bestaat een eigen referentiekader: de OWASP API Security Top 10. Dit is een aparte lijst naast de bekende OWASP Top 10 voor webapplicaties, juist omdat API-specifieke risico's een eigen karakter hebben. De actuele editie kent tien categorieën die wij tijdens een API-pentest systematisch aflopen.

API1 Broken Object Level Authorization (BOLA). Dit is verreweg de meest voorkomende en meest impactvolle API-kwetsbaarheid. Het komt erop neer dat een endpoint een object teruggeeft op basis van een identifier zonder te controleren of de aanvrager recht heeft op juist dat object. Wij testen dit door met account A een verzoek te doen en vervolgens de identifier te vervangen door die van account B. Slaagt dat, dan kan een gebruiker de gegevens van iedere andere gebruiker opvragen. Het is de digitale variant van een genummerde kluis waarvan elke sleutel op elk slot past.

API2 Broken Authentication. Hier draait het om de manier waarop de API identiteit vaststelt. We testen op zwakke of ontbrekende tokenvalidatie, tokens die niet verlopen, voorspelbare API-sleutels, en inlog- en herstelprocessen zonder bescherming tegen brute force en credential stuffing.

API3 Broken Object Property Level Authorization. Deze categorie combineert het te veel teruggeven van gegevens en het te veel accepteren van gegevens. Een API die een volledig gebruikersobject teruggeeft inclusief interne velden, of die bij een update klakkeloos elk meegestuurd veld overneemt (mass assignment), stelt de aanvaller in staat om bijvoorbeeld de eigen rol naar beheerder te zetten.

API4 Unrestricted Resource Consumption. Zonder limieten op verzoeken, resultaatgrootte of rekentijd kan een aanvaller de dienst overbelasten of onnodig hoge kosten veroorzaken. We beoordelen rate limiting, paginering en beperkingen op zware bewerkingen.

API5 Broken Function Level Authorization. Waar BOLA over objecten gaat, gaat dit over functies. Kan een gewone gebruiker een beheerfunctie aanroepen door simpelweg het juiste endpoint of de juiste HTTP-methode te raden? Administratieve endpoints die alleen door de frontend worden verborgen, maar niet aan de serverzijde worden afgeschermd, zijn een klassieke bevinding.

API6 Unrestricted Access to Sensitive Business Flows. Deze categorie kijkt naar geautomatiseerd misbruik van legitieme functionaliteit, zoals het massaal opkopen van voorraad of het geautomatiseerd aanmaken van accounts. De vraag is of er tegenmaatregelen zijn tegen geautomatiseerd misbruik van gevoelige bedrijfsprocessen.

API7 Server Side Request Forgery. Als een API op basis van door de gebruiker aangeleverde URLs verzoeken uitvoert, kan een aanvaller de server dwingen interne systemen of cloud-metadata-endpoints te benaderen. We testen of externe invoer wordt gevalideerd voordat de server zelf een verbinding opzet.

API8 Security Misconfiguration. Verkeerde CORS-instellingen, ontbrekende beveiligingsheaders, uitgebreide foutmeldingen en ingeschakelde debugfunctionaliteit vergroten het aanvalsoppervlak. Dit zijn vaak snel te verhelpen bevindingen.

API9 Improper Inventory Management. Organisaties raken het overzicht kwijt over welke API-versies waar draaien. Een vergeten testomgeving of een oude, ongepatchte v1 naast de actuele v2 is een geliefd doelwit. We proberen daarom actief niet-gedocumenteerde en verouderde endpoints te vinden.

API10 Unsafe Consumption of APIs. Applicaties vertrouwen data van externe APIs vaak meer dan invoer van gebruikers. Wij beoordelen of antwoorden van derde partijen met dezelfde argwaan worden behandeld als gebruikersinvoer.

Onze aanpak in de praktijk

Een goede API-pentest begint met de documentatie. Een OpenAPI- of Swagger-specificatie, of een Postman-collectie, versnelt het werk aanzienlijk, maar we vertrouwen er niet blind op. Juist de endpoints die niet in de documentatie staan zijn interessant. We werken bij voorkeur met minimaal twee testaccounts met verschillende rechten, zodat we autorisatie tussen gebruikers onderling en tussen rolniveaus grondig kunnen toetsen. Vervolgens combineren we geautomatiseerde tooling voor brede dekking met handmatig onderzoek naar de logica achter de endpoints. Dat handwerk is bij APIs doorslaggevend, omdat autorisatie- en business-logic-fouten zich niet met een scanner laten vinden. Ze vragen om begrip van wat de applicatie geacht wordt te doen en wat een gebruiker juist niet zou mogen.

Van bevinding naar herstel

De waarde van een API-pentest zit in wat erna gebeurt. Ons rapport beschrijft per bevinding de impact, de exploiteerbaarheid en een concreet hersteladvies, met een prioritering op basis van werkelijk risico in plaats van alleen een CVSS-score. Na herstel voeren we standaard een retest uit, want een bevinding is pas gesloten als die aantoonbaar en volledig is opgelost. Overweegt u een pentest? Neem dan expliciet de APIs in de scope mee, ook de interne en de mobiele. Dat is vaak juist waar het echte risico zit.