Een API heeft een gateway, gebruikers melden zich aan met geldige tokens en alle verbindingen lopen via HTTPS. Toch kan een medewerker mogelijk een dossier van een andere klant opvragen. Hoe kan dat wanneer de toegang technisch is beveiligd?
Stel je een fictief klantenportaal voor. Een medewerker ziet dossier 481, past in het API-verzoek het dossiernummer aan naar 482 en krijgt informatie van een andere organisatie terug. Het token is geldig. De gateway laat het verzoek door. Maar de applicatie heeft niet gecontroleerd of deze gebruiker juist dit dossier mag bekijken. Dat is het onderscheid tussen authenticatie en autorisatie — en precies waarom API-beveiliging meer vraagt dan een veilige toegangspoort.
Wat NIST daadwerkelijk heeft bijgewerkt
Het Amerikaanse National Institute of Standards and Technology (NIST) publiceerde SP 800-228: Guidelines for API Protection for Cloud-Native Systems oorspronkelijk in juni 2025. Op 13 maart 2026 werd de richtlijn bijgewerkt met twee bijlagen: een indeling van API-risico’s naar categorie en aanbevolen beveiligingsmaatregelen per fase van de API-levenscyclus.
De publicatie behandelt risico’s tijdens ontwikkeling en runtime, mogelijke beveiligingsmaatregelen en de afwegingen tussen implementaties. NIST schrijft daarmee niet één specifieke gateway of leverancier voor, maar stimuleert een stapsgewijze, risicogebaseerde aanpak. De officiële NIST-publicatie maakt het onderscheid tussen oorspronkelijke uitgave en update expliciet.
Een geldig token geeft niet automatisch toegang tot dossier 482
Een API-gateway kan verkeer routeren, verbindingen beveiligen, toegangscontroles ondersteunen en overmatig verkeer beperken. Een identity provider kan identiteit en tokens beheren. Maar daarmee weet de applicatie nog niet vanzelf welke objecten iemand mag zien en welke handelingen zijn toegestaan.
OWASP beschrijft dit probleem als Broken Object Level Authorization (BOLA). De gebruiker mag het endpoint mogelijk aanroepen, maar mag niet bij ieder object dat via een ID wordt opgevraagd. Objectautorisatie moet daarom voor relevante verzoeken worden afgedwongen, óók wanneer het token technisch geldig is.
In een multi-tenant omgeving is de vraag extra belangrijk: aan welke organisatie behoort het dossier toe, waar komt die tenantcontext vandaan en kan de gebruiker die beïnvloeden? Een tenant-ID uit een onbetrouwbare requestparameter is op zichzelf geen bewijs van toestemming.
De kwetsbaarheid kan in een andere route zitten
Misschien controleert het systeem keurig wie één dossier mag lezen. Maar doet de zoekfunctie dat ook? En een lijstweergave, bulkexport, rapportage of oudere API-versie? Een veilige detailpagina is geen bewijs dat gegevens niet via een ander endpoint uitlekken.
Voor het fictieve dossierportaal is daarom niet alleen GET /api/cases/481 relevant. Ook filters en exports moeten de juiste organisatie- en objectrechten afdwingen. De frontend kan daarbij helpen met een begrijpelijke interface, maar mag nooit de enige beveiligingsgrens zijn.
Een toegestaan object betekent nog geen toegestane handeling
Een medewerker kan bevoegd zijn een dossier te lezen, maar niet om het te wijzigen nadat het is afgesloten. Bij een betaling kan een opnieuw verstuurd verzoek tot een dubbele verwerking leiden als de applicatie geen passend mechanisme voor idempotentie en transacties heeft.
Dit zijn niet allemaal dezelfde kwetsbaarheden als BOLA. Ze maken wel duidelijk waarom authenticatie, objectautorisatie en bedrijfsregels verschillende verantwoordelijkheden hebben. Rate limiting kan misbruik helpen beperken, maar vervangt geen controle of de handeling zelf mag plaatsvinden.
Een test moet juist laten zien wat níét mag
Maak voor een gecontroleerde testomgeving twee gebruikers in verschillende tenants met elk eigen dossiers. Laat de eerste gebruiker met een geldig token het dossier van de tweede opvragen, wijzigen en exporteren. Controleer dat verboden handelingen worden geweigerd en dat gevoelige gegevens niet alsnog in response, foutmelding of logging verschijnen.
Breid de negatieve tests uit met verlopen tokens, ingetrokken rechten, alternatieve zoekroutes en herhaalde requests. Controleer ook de toestand van de database. Alleen een HTTP-foutcode bewijst niet dat een verboden wijziging nergens is uitgevoerd.
De test moet daarnaast aantonen welke beveiligingslaag verantwoordelijk is. Waar wordt identiteit gevalideerd, waar vindt objectautorisatie plaats en waar worden bedrijfsregels gecontroleerd? Als teams naar elkaar verwijzen zonder eigenaar of testbewijs, kan een belangrijke controle ontbreken.
Meer lagen leveren niet automatisch meer veiligheid op
Een extra proxy, gateway of beveiligingsproduct kan een nuttige maatregel zijn. Maar iedere laag introduceert configuratie, afhankelijkheden en beheer. De werkelijke vraag is niet hoeveel producten er aanwezig zijn, maar welke risico’s ze afdekken en hoe dat aantoonbaar werkt.
Een eenvoudige interne API vraagt een andere risicobeoordeling dan een publiek multi-tenant platform met externe partners. Leg per endpoint en relevante handeling vast wie toegang mag krijgen, hoe dat wordt vastgesteld, welke uitzonderingen bestaan en hoe het team de controle kan testen en onderhouden.
Dat onderhoud hoort bij de beveiliging: sleutelrotatie, dependency-updates, monitoring en herstelprocedures moeten uitvoerbaar zijn zonder onnodig secrets of persoonsgegevens vast te leggen. Lees in dit verband ook Dogteams artikel over technical debt en onderhoudbaarheid.
De kwaliteit blijkt wanneer een geldig verzoek wordt geweigerd
Een gateway kan noodzakelijk zijn, maar maakt een API niet vanzelf veilig. De beslissende toets komt wanneer iemand met een geldig token iets probeert waarvoor geen toestemming bestaat. Herkent de applicatie dat onderscheid, weigert ze de handeling en kan het team uitleggen waarom?
API-beveiliging gaat uiteindelijk minder over het aantal beveiligingslagen dan over de juiste verantwoordelijkheden, controleerbare autorisatie en beheersbare systemen.
Bronnen
- NIST SP 800-228-upd1 — Guidelines for API Protection for Cloud-Native Systems (13 maart 2026)
- OWASP API Security Top 10 (2023) — Broken Object Level Authorization
Neem contact met ons op
Vertel ons waarmee we kunnen helpen; we reageren binnen twee werkdagen.
