Uw IT-team heeft een firewall geïnstalleerd, de virusscanner draait 24/7 en de WAF staat aan. Toch blijft er een groeiend risico dat deze tools structureel missen: de API’s die uw applicaties, mobiele apps en partnerintegraties laten communiceren. Deze “digitale deuren” zijn inmiddels de meest frequente aanvalsvector geworden, en de meeste organisaties hebben geen idee hoeveel deuren er eigenlijk openstaan.
Waarom API’s uw grootste aanvalsoppervlak zijn geworden
De meeste IT-professionals kennen API’s als de lijm tussen systemen: de gestandaardiseerde manier waarop uw frontend communiceert met de backend, hoe microservices onderling data uitwisselen en hoe externe partijen integreren met uw platform. REST, GraphQL, gRPC — de technologie is gemeengoed.
Wat minder gemeengoed is: de security-implicaties van de shift naar microservices-architecturen. Waar u vroeger één monolithische applicatie beveiligde met een handvol endpoints, heeft u nu tientallen of honderden services die via API’s met elkaar praten. Eén gebruikersactie op uw webshop kan een keten van interne calls activeren: Checkout naar Inventory, naar Payment, naar Fraud Detection, naar Shipping. Elk van die endpoints is een potentieel aanvalspunt.
Het probleem zit niet in de technologie zelf, maar in de autorisatielogica. Een API kan technisch correct functioneren en toch fundamenteel onveilig zijn. Denk aan een endpoint dat keurig valideert of een gebruiker is ingelogd, maar vergeet te checken of die gebruiker ook daadwerkelijk eigenaar is van de opgevraagde resource. Of een endpoint dat blindelings alle velden uit een JSON-payload accepteert, inclusief een “role”: “admin” die de aanvaller zelf heeft toegevoegd.
Dit zijn geen edge cases. Het zijn de meest voorkomende kwetsbaarheden in productie-API’s.
Waarom uw firewall en virusscanner API-aanvallen missen
“Wij geven al veel uit aan beveiliging. Waarom stoppen die tools deze aanvallen niet?” Het is een vraag die we regelmatig horen. Het antwoord ligt in het fundamentele verschil tussen infrastructuuraanvallen en applicatielogica-aanvallen.
De virusscanner zoekt naar malware. Een API-aanval bevat geen malware. Wanneer een aanvaller probeert toegang te krijgen tot andermans facturen door simpelweg het factuurnummer in de URL te veranderen (van /api/facturen/1001 naar /api/facturen/1002), verstuurt hij een perfect geldig HTTP-verzoek. Geen virus, geen verdachte bijlage, gewoon tekst. De virusscanner ziet niets verkeerds.
De firewall bewaakt poorten. API’s gebruiken poort 80 en 443, dezelfde poorten als uw normale webverkeer. Die poorten blokkeren betekent uw website offline halen. Voor een firewall ziet een API-aanval er identiek uit aan een legitiem websitebezoek.
De WAF zoekt naar bekende patronen. Web Application Firewalls herkennen SQL-injecties en cross-site scripting. Maar wanneer een aanvaller vraagt om /api/orders/123 in plaats van /api/orders/124, ziet de WAF twee identieke, geldige verzoeken. Hij weet niet dat Gebruiker A geen toegang hoort te hebben tot Order 124.
De kwaadaardigheid zit niet in de techniek, maar in de context. En die context begrijpen uw traditionele beveiligingstools simpelweg niet.
Shadow en Zombie API’s: de deuren die u niet kent
Naast de bekende API’s heeft vrijwel elke organisatie te maken met twee verborgen categorieën die buiten het zicht van het securityteam opereren.
Shadow API’s ontstaan wanneer ontwikkelaars of afdelingen snel een oplossing bouwen zonder de centrale IT-afdeling in te schakelen. Het marketingteam dat een externe partij inhuurt voor een promotionele microsite met eigen API. De ontwikkelaar die een “tijdelijke” achterdeur maakt om testen te vergemakkelijken. Deze API’s staan niet in de documentatie, worden niet gemonitord en bevinden zich vaak niet achter uw beveiligingsinfrastructuur.
Zombie API’s zijn het gevolg van slechte lifecycle management. Uw team brengt een nieuwe API-versie uit met verbeterde beveiliging, maar durft de oude versie niet direct uit te schakelen. Sommige gebruikers hebben hun app immers nog niet geüpdatet. Maanden later is die oude versie vergeten, de oorspronkelijke ontwikkelaars zijn vertrokken en de API draait nog steeds met alle bekende kwetsbaarheden die in de nieuwe versie al lang zijn gepatcht.
Aanvallers weten dit. Ze scannen specifiek op /api/v1/ endpoints, zelfs wanneer uw app allang /api/v2/ gebruikt.
De OWASP API Security Top 10: waar het écht misgaat
Het Open Web Application Security Project onderhoudt een specifieke Top 10 voor API-risico’s. De nummer één? Broken Object Level Authorization (BOLA), simpel gezegd: de API controleert wel of iemand is ingelogd, maar niet of diegene de opgevraagde data ook daadwerkelijk mag zien.
Dit is geen theoretisch risico. Een aanvaller logt in, ziet zijn eigen transactiegeschiedenis, verandert het rekeningnummer in de URL en krijgt de transacties van een vreemde teruggestuurd. Geen hack in de traditionele zin, gewoon een vraag stellen die het systeem ten onrechte beantwoordt.
Andere veelvoorkomende problemen zijn onder meer gebrekkige authenticatie (zwakke wachtwoorden, slecht geconfigureerde tokens), het blootstellen van te veel data in API-responses en het ontbreken van limieten op het aantal verzoeken dat een gebruiker kan doen.
Hoe u uw API’s wél beveiligt
De oplossing begint niet bij een nieuwe tool, maar bij zichtbaarheid en governance.
Breng uw API-landschap in kaart. Gebruik geautomatiseerde discovery-tools om alle actieve endpoints te identificeren, inclusief de Shadow en Zombie API’s die buiten uw documentatie vallen. Vergelijk wat u detecteert met wat u denkt te hebben.
Integreer security in het ontwikkelproces. Wacht niet tot de applicatie live staat. Gebruik threat modeling in de ontwerpfase om logische fouten te identificeren voordat er code wordt geschreven. Scan broncode op hardcoded credentials en onveilige configuraties.
Test de bedrijfslogica, niet alleen de techniek. Standaard vulnerability scanners missen BOLA en andere logische fouten. Laat ethische hackers de bedrijfslogica handmatig testen. Zij begrijpen de “intentie” van uw applicatie en vinden kwetsbaarheden die geautomatiseerde tools over het hoofd zien.
Implementeer een deprecation-beleid. Kondig bij elke nieuwe API-versie een harde einddatum aan voor de oude versie. Test wie er nog gebruik van maakt door de oude versie periodiek kort uit te schakelen. En verwijder de code daadwerkelijk wanneer de deadline verstrijkt.
Veelgestelde vragen over API security
Wat is het verschil tussen een Shadow API en een Zombie API?
Een Shadow API is actief en in gebruik, maar ongedocumenteerd en onbekend bij het securityteam. Een Zombie API is een verouderde, vergeten API die nog steeds draait met vaak ongepatchte kwetsbaarheden. Beide vormen een risico omdat ze buiten uw beveiligingsmonitoring vallen.
Waarom detecteert mijn WAF geen API-aanvallen?
Web Application Firewalls zoeken naar bekende aanvalspatronen zoals SQL-injecties. API-aanvallen maken vaak misbruik van bedrijfslogica, bijvoorbeeld door een ander gebruikers-ID in te vullen. Technisch gezien zijn dit geldige verzoeken die de WAF niet kan onderscheiden van legitiem verkeer.
Moet mijn KMO zich zorgen maken over API security?
Ja. Zodra uw bedrijf een mobiele app, webportaal of partnerintegratie heeft, gebruikt u API’s. Die API’s zijn bereikbaar via het internet en vormen een potentiële ingang voor aanvallers, ongeacht de grootte van uw organisatie.
Hoe ontdek ik welke API’s mijn organisatie allemaal heeft?
Geautomatiseerde API discovery-tools kunnen uw netwerk, cloud-omgevingen en API-gateways scannen om alle actieve endpoints in kaart te brengen. Vergelijk dit met uw documentatie om Shadow en Zombie API’s te identificeren.
Wat is BOLA en waarom is het zo gevaarlijk?
BOLA (Broken Object Level Authorization) betekent dat een API niet controleert of de ingelogde gebruiker daadwerkelijk toegang heeft tot de opgevraagde data. Een aanvaller kan simpelweg ID’s aanpassen om toegang te krijgen tot gegevens van andere gebruikers. Het is de nummer één API-kwetsbaarheid volgens OWASP.
Kan ik API security uitbesteden?
Ja. Een gespecialiseerde partner kan uw API-landschap in kaart brengen, pentests uitvoeren die de bedrijfslogica testen en u helpen met het opzetten van governance en monitoring. Dit is vooral waardevol wanneer uw interne IT-team de capaciteit of specifieke expertise mist.
Tijd voor een API Security Check?
Wilt u weten hoeveel “onzichtbare deuren” uw organisatie heeft en of ze goed op slot zitten? Onze OSCP-gecertificeerde pentesters testen niet alleen de techniek, maar ook de bedrijfslogica van uw API’s. We vinden de kwetsbaarheden vóór de criminelen dat doen.
Neem contact op voor een vrijblijvend gesprek of vraag direct een offerte aan voor een API Security Assessment. Tot 45% subsidieerbaar via de KMO-portefeuille.
