API’s vormen de ruggengraat van moderne applicaties. Webapps, mobiele apps en externe diensten communiceren vrijwel altijd via API-koppelingen. Daardoor bevatten API’s vaak precies de functionaliteit waar aanvallers naar op zoek zijn: toegang tot data, gebruikersaccounts en bedrijfslogica.
Veel organisaties vertrouwen daarom sterk op tokens voor de beveiliging van hun API’s. Denk aan JWT-tokens, API-keys of OAuth-tokens. Als een gebruiker een geldig token heeft, mag hij requests doen naar de API.
Op papier klinkt dat veilig. In de praktijk blijkt het echter regelmatig mis te gaan.
Tijdens pentesten zien we vaak dat een API technisch correct gebruikmaakt van tokens, maar dat de autorisatie erachter niet goed is ingericht. Daardoor kan een aanvaller alsnog toegang krijgen tot gegevens of functionaliteiten die niet voor hem bedoeld zijn.
In dit artikel leggen we uit waarom tokens alleen niet voldoende zijn voor API-beveiliging en waar het in de praktijk vaak fout gaat.
Tokens bewijzen wie je bent, niet wat je mag
Een token wordt meestal gebruikt om te controleren wie een gebruiker is. Nadat een gebruiker is ingelogd ontvangt hij bijvoorbeeld een JWT-token dat bij elke API-request wordt meegestuurd.
De API controleert vervolgens of het token geldig is. Als dat zo is, wordt de request geaccepteerd.
Veel systemen stoppen hier. Maar dat is precies waar het risico begint.
Een geldig token bewijst namelijk alleen dat een gebruiker is geauthenticeerd. Het zegt niets over welke data of functionaliteiten die gebruiker mag benaderen.
Autorisatie (bepalen wat iemand mag doen) is vaak complexer dan authenticatie. En juist daar ontstaan in de praktijk veel kwetsbaarheden.
Authenticatie vs autorisatie in API-beveiliging
Bij API-beveiliging worden authenticatie en autorisatie vaak door elkaar gehaald, terwijl het fundamenteel verschillende controles zijn.
Authenticatie bepaalt wie een gebruiker is. Dit gebeurt bijvoorbeeld via een loginproces waarbij een token wordt uitgegeven.
Autorisatie bepaalt wat die gebruiker mag doen. Dat betekent dat de API moet controleren of een gebruiker daadwerkelijk toegang heeft tot een specifiek object, record of functionaliteit.
Een API kan dus perfect geauthenticeerd zijn en toch kwetsbaar blijven wanneer autorisatie ontbreekt. In dat geval kan een gebruiker met een geldig token alsnog gegevens opvragen die niet voor hem bedoeld zijn.
Juist daarom richten veel API pentesten zich op het controleren van autorisatie en niet alleen op authenticatiemechanismen.
Het klassieke voorbeeld: IDOR
Een veelvoorkomend probleem bij API’s is een kwetsbaarheid die bekendstaat als Insecure Direct Object Reference (IDOR).
Stel dat een API een endpoint heeft zoals:
/api/users/123/profile
De applicatie controleert of de gebruiker een geldig token heeft. Vervolgens stuurt de API de profielgegevens van gebruiker 123 terug.
Maar wat gebeurt er als een aanvaller het ID aanpast?
/api/users/124/profile
Als de API alleen controleert of het token geldig is, en niet of de gebruiker daadwerkelijk toegang heeft tot dat specifieke profiel, kan een aanvaller gegevens van andere gebruikers opvragen.
Dit probleem komt vaker voor dan veel organisaties verwachten. Niet omdat developers slechte code schrijven, maar omdat autorisatie-logica vaak ingewikkeld wordt wanneer applicaties groeien.
Autorisatieproblemen ontstaan vaak bij groei
Veel API-kwetsbaarheden ontstaan niet bij de eerste versie van een applicatie. Ze ontstaan later, wanneer systemen complexer worden.
Een applicatie begint bijvoorbeeld met één type gebruiker en een paar eenvoudige endpoints. Later komen er nieuwe functionaliteiten bij:
- extra gebruikersrollen
- nieuwe API-endpoints
- integraties met andere systemen
- mobiele apps die dezelfde API gebruiken
Elke uitbreiding maakt de autorisatielogica ingewikkelder. Als er geen duidelijke centrale controle bestaat, kan het gebeuren dat bepaalde endpoints minder strikt worden gecontroleerd.
Tijdens pentesten zien we daarom regelmatig dat oudere of minder gebruikte endpoints andere beveiligingsregels hebben dan nieuwe onderdelen van de applicatie.
Veelgemaakte fouten in API autorisatie
In de praktijk ontstaan kwetsbaarheden in API’s vaak niet doordat authenticatie ontbreekt, maar doordat autorisatie onvolledig of inconsistent wordt toegepast.
Ontwikkelteams controleren bijvoorbeeld wel of een gebruiker is ingelogd, maar vergeten te controleren of die gebruiker daadwerkelijk toegang heeft tot specifieke data.
Veelvoorkomende fouten zijn onder andere:
- het ontbreken van object-level autorisatie
- te brede gebruikersrollen
- vertrouwen op client-side controles
- endpoints die geen autorisatiecontrole uitvoeren
- nieuwe API-functionaliteiten zonder consistente securityregels
Dit soort fouten zijn lastig te detecteren met automatische vulnerability scanners. Ze worden meestal pas zichtbaar wanneer iemand systematisch onderzoekt hoe verschillende API-requests zich tot elkaar verhouden.
Tokens kunnen te veel rechten geven
Een ander probleem ontstaat wanneer tokens te veel rechten bevatten.
Sommige systemen gebruiken tokens die impliciet toegang geven tot meerdere onderdelen van de applicatie. Bijvoorbeeld omdat een token gekoppeld is aan een gebruikersrol met brede rechten.
In zo’n situatie kan een aanvaller die een token bemachtigt vaak meer doen dan verwacht.
Denk bijvoorbeeld aan scenario’s waarbij een gebruiker met een normaal account via de API toch toegang krijgt tot beheerfunctionaliteiten of gevoelige data. Niet omdat de token zelf onveilig is, maar omdat de autorisatie-regels te ruim zijn gedefinieerd.
Dit soort problemen wordt vaak pas zichtbaar wanneer een aanvaller verschillende endpoints gaat combineren.
Waarom API-keys en simpele tokens vaak niet voldoende zijn
Veel API’s worden beveiligd met een eenvoudige vorm van authenticatie, zoals een subscription key, API-key of statisch token. Dit mechanisme controleert of een client toegang heeft tot de API, maar zegt meestal weinig over welke specifieke acties of data zijn toegestaan.
Het probleem is dat deze keys vaak op applicatieniveau werken. Als een client een geldige key heeft, krijgt deze in veel gevallen toegang tot alle endpoints die onder die key vallen. Daardoor ontbreekt een fijnmazige controle op gebruikersniveau.
Bij gevoelige data of complexe applicaties is dat meestal onvoldoende.
Moderne API-architecturen maken daarom vaak gebruik van standaarden zoals OAuth 2.0 en OpenID Connect. Deze frameworks maken het mogelijk om tokens te koppelen aan specifieke gebruikers, rollen en scopes. Hierdoor kan een API nauwkeuriger bepalen welke acties een client mag uitvoeren.
Maar zelfs met OAuth 2.0 blijft autorisatie een verantwoordelijkheid van de applicatie zelf. Een geldig access token betekent alleen dat een client is geauthenticeerd en bepaalde scopes heeft gekregen. De API moet nog steeds controleren of de gebruiker daadwerkelijk toegang heeft tot het specifieke object of de data die wordt opgevraagd.
Hoe autorisatie in API’s wél goed wordt ingericht
Als tokens alleen authenticatie regelen, moet autorisatie op een andere manier worden gecontroleerd. In de praktijk betekent dit dat een API niet alleen moet controleren wie een gebruiker is, maar ook wat die gebruiker mag doen.
Een robuuste autorisatiestructuur bestaat meestal uit meerdere controles.
Controle op objectniveau
Elke API-request die data ophaalt of wijzigt moet controleren of de gebruiker daadwerkelijk toegang heeft tot het betreffende object.
Rol- en rechtenmodel
Gebruikersrollen moeten duidelijk gedefinieerde rechten hebben. In plaats van brede permissies krijgen rollen alleen toegang tot functionaliteiten die noodzakelijk zijn voor hun taken.
Consistente autorisatie in alle services
In moderne architecturen communiceren meerdere services via API’s met elkaar. Autorisatie moet daarom ook op API-niveau worden afgedwongen en niet alleen in de frontend.
Controle op business logica
Naast technische autorisatie moet ook de bedrijfslogica worden gecontroleerd. Acties die technisch mogelijk zijn, zijn niet altijd functioneel toegestaan.
Waarom vulnerability scanners deze problemen vaak missen
Veel organisaties gebruiken vulnerability scanners om hun applicaties te scannen op kwetsbaarheden. Deze tools zijn waardevol voor het detecteren van bekende kwetsbaarheden, zoals verouderde software of misconfiguraties.
Maar autorisatieproblemen en fouten in business logica zijn vaak moeilijk automatisch te detecteren.
Een scanner kan bijvoorbeeld zien dat een endpoint bestaat, maar niet of een gebruiker eigenlijk toegang zou moeten hebben tot de data die dat endpoint terugstuurt.
Daarom worden veel API-kwetsbaarheden pas zichtbaar tijdens een API pentest, waarbij securityspecialisten handmatig analyseren hoe de applicatie werkt en hoe verschillende requests met elkaar samenhangen.
Praktijkvoorbeeld: wanneer een JWT-token niet genoeg is
Tijdens een API pentest op een SaaS-applicatie ontdekten we dat gebruikers met een geldig JWT-token hun eigen projectgegevens konden ophalen via een endpoint zoals /api/projects/{id}. De API controleerde netjes of het token geldig was, maar controleerde niet of de gebruiker daadwerkelijk toegang had tot het gevraagde project-ID. Door simpelweg het ID in de request te verhogen, konden andere projecten worden opgevraagd, inclusief klantgegevens en interne notities. Technisch werkte de authenticatie dus correct, maar de autorisatie ontbrak volledig. Met een klein script kon een aanvaller zo in korte tijd honderden projecten uitlezen.
API-beveiliging gaat verder dan tokens
Tokens vormen een belangrijk onderdeel van moderne API-beveiliging, maar ze lossen slechts een deel van het probleem op. Een geldig token betekent dat een gebruiker is geauthenticeerd, maar zegt niets over de specifieke rechten die die gebruiker heeft binnen een applicatie.
Kwetsbaarheden ontstaan meestal wanneer autorisatiecontroles ontbreken of inconsistent worden toegepast. Daardoor kunnen gebruikers via de API gegevens opvragen of acties uitvoeren die eigenlijk buiten hun toegangsrechten vallen.
Voor organisaties die afhankelijk zijn van API’s voor hun applicaties, integraties of mobiele diensten is het daarom essentieel om verder te kijken dan alleen token-gebaseerde authenticatie. Regelmatig testen van API’s op autorisatieproblemen helpt om kwetsbaarheden vroegtijdig te identificeren en te voorkomen dat gevoelige data toegankelijk wordt voor onbevoegden.
Wil je weten hoe jouw API omgaat met autorisatie en toegang tot gevoelige data? Met een API pentest krijg je inzicht in de werkelijke risico’s binnen jouw applicatie.