De OWASP Top 10 is de bijbel van webapplicatiebeveiliging. Maar ergens rond 2015 realiseerde de security-gemeenschap zich dat API's een ander beest zijn. Een webapplicatie serveert HTML aan mensen. Een API serveert data aan machines. En machines zijn veel beter in het vinden van dingen die niet de bedoeling zijn.
Waarom API's anders zijn
Bij een webapplicatie bepaalt de interface wat de gebruiker kan doen. Er is een formulier met drie velden, dus de gebruiker vult drie velden in. Bij een API is er geen interface — alleen een endpoint dat data accepteert. En de "gebruiker" is een stuk software dat net zo makkelijk duizend verzoeken per seconde kan sturen als één.
Dat verandert het dreigingslandschap fundamenteel. De aanvalsvectoren verschuiven van "wat kan ik de gebruiker laten doen?" naar "wat accepteert deze endpoint als ik het op onverwachte manieren aanroep?"
De OWASP API Security Top 10
1. Broken Object Level Authorization (BOLA)
De nummer één, en terecht. BOLA is wat er gebeurt als een API je toegang geeft tot objecten die niet van jou zijn, simpelweg door het ID in de URL te veranderen. GET /api/users/123/orders toont jouw bestellingen. GET /api/users/124/orders toont die van iemand anders. Als de API niet controleert of jij user 124 bent, heb je een BOLA.
Het klinkt te dom om waar te zijn, maar het is de meest voorkomende API-kwetsbaarheid ter wereld. Uber, Facebook, Bumble — allemaal zijn ze er door getroffen. Het probleem is dat het zo makkelijk is om te missen. Elke endpoint, elke parameter, elke combinatie moet gecontroleerd worden.
2. Broken Authentication
API-authenticatie is een mijnenveld. Tokens die niet verlopen, JWT's zonder signature-verificatie, API-keys die in de broncode staan, authenticatie die ontbreekt op "interne" endpoints die toch bereikbaar zijn vanaf het internet. Het is een lange lijst van dingen die mis kunnen gaan, en bijna elke organisatie heeft er minstens één van.
3. Broken Object Property Level Authorization
Fijnmaziger dan BOLA. Je mag het object wel zien, maar niet alle velden. Een API die gebruikersprofielen retourneert, zou het e-mailadres mogen tonen maar niet het salaris. Tenzij de ontwikkelaar het ORM-model één-op-één naar JSON serialiseert — en dat is precies wat veel frameworks standaard doen.
4. Unrestricted Resource Consumption
Geen rate limiting. Geen paginering. Geen maximale bestandsgrootte. Een API die het toestaat dat je een miljoen records in één keer opvraagt, of een bestand van 10 GB upload, of honderdduizend verzoeken per minuut stuurt. Het is niet zozeer een kwetsbaarheid als wel een uitnodiging tot misbruik.
5. Broken Function Level Authorization
De admin-endpoints die bereikbaar zijn voor gewone gebruikers. GET /api/users is voor iedereen, maar DELETE /api/users/123 zou dat niet moeten zijn. Toch is het verbazingwekkend hoe vaak de autorisatiecontrole op het ene endpoint wél aanwezig is en op het andere niet.
6. Unrestricted Access to Sensitive Business Flows
Sommige acties zijn niet onveilig per se, maar worden problematisch op schaal. Een ticket kopen is normaal. Alle tickets kopen via een geautomatiseerd script is scalperen. De API ziet geen verschil — het zijn allebei geldige requests.
7. Server Side Request Forgery (SSRF)
Een API die URLs accepteert als input en die vervolgens ophaalt, kan worden misbruikt om interne diensten te benaderen. "Haal deze afbeelding op: http://169.254.169.254/latest/meta-data/" — en plots heb je de AWS-metadata van de server, inclusief IAM-credentials.
8. Security Misconfiguration
CORS-headers die alles toestaan. Debug-modus in productie. Standaardwachtwoorden. Onnodige HTTP-methoden. Verbose foutmeldingen die de stacktrace tonen. De lijst is eindeloos en altijd actueel.
9. Improper Inventory Management
Je kunt niet beveiligen wat je niet weet dat bestaat. Vergeten API-versies die nog draaien (/api/v1/ naast /api/v3/), test-endpoints in productie, ongedocumenteerde endpoints die door een stagiair zijn gebouwd en nooit zijn opgeruimd. Shadow API's zijn het shadow IT van de applicatielaag.
10. Unsafe Consumption of APIs
Je API is zo veilig als de zwakste API die hij aanroept. Als jouw service data ophaalt van een derde partij en die zonder validatie verwerkt, erft jouw API de kwetsbaarheden van die derde partij. Vertrouw nooit data van een externe bron — zelfs niet als die bron een "vertrouwde partner" is.
Wat kun je doen?
De oplossing is niet spectaculair, maar effectief: autorisatie op elk endpoint, rate limiting overal, input validatie op alles, output filtering, een compleet API-inventaris, en — misschien het allerbelangrijkste — regelmatig testen. API-security is niet iets dat je één keer instelt. Het is een doorlopend proces, net als de rest van beveiliging.