Waarom API's bijzonder kwetsbaar zijn
Programmatic interfaces verbinden interne en externe systemen, verwerken gevoelige gegevens en werken geautomatiseerd — zonder menselijke validatie bij elke aanroep. Traditionele netwerkperimeterbeveiligingen zijn onvoldoende wanneer elke geautoriseerde client duizenden verzoeken per minuut kan doen. De OWASP API Security Top 10 documenteert terugkerende kwetsbaarheidsklassen, waarvan vele niet het gevolg zijn van codefouten maar van ontoereikend beveiligingsontwerp op architectuurniveau.
Authenticatie en autorisatie — het fundament
OAuth2 met Authorization Code flow en PKCE is de gouden standaard voor API's die toegankelijk zijn via clientapplicaties. Voor server-naar-server communicatie is de Client Credentials flow met kortlevende toegangstokens geschikt. Cruciale fouten die in de ontwerpfase moeten worden geëlimineerd zijn: opslag van tokens in localStorage in plaats van vluchtig geheugen, ontbrekende validatie van scopebevoegdheden bij elke aanroep, het overslaan van audience-veldverificatie in het JWT-token, en het gebruik van statische API-sleutels zonder rotatiemechanisme.
- Toegangstokens: maximale levensduur 15-60 minuten
- Verversingstokens: opgeslagen in beveiligde, httpOnly cookies of veilige serveropslag
- API-sleutelrotatie: verplicht, geautomatiseerd, zonder downtime
- Inspectie van elke aanroep op scopebevoegdheden — niet alleen bij inloggen
Rate limiting als bescherming tegen misbruik
Het beperken van het aantal aanroepen per tijdseenheid beschermt API's tegen meerdere bedreigingsklassen tegelijk: brute force-aanvallen op inloggegevens, datascraping, DDoS-aanvallen gericht op bedrijfslogica en onbedoelde overbelasting door defecte clients. Effectieve rate limiting vereist granulariteit — andere limieten voor niet-geauthenticeerde verzoeken, andere voor geauthenticeerde gebruikers, andere voor partners met verhoogd vertrouwen. Limieten moeten worden toegepast op IP-adres, gebruikers-ID en API-sleutel gecombineerd.
Het is belangrijk om op correcte foutcodes te letten — code 429 Too Many Requests moet een Retry-After header bevatten, wat correct gedrag van clients mogelijk maakt en het aantal herhaalpogingen vermindert. Te restrictieve limieten veroorzaken frustratie bij gebruikers en bemoeilijken probleemdiagnose.
WAF en API-verkeersinspectie
Next-generation Web Application Firewalls begrijpen de structuur van API's — ze verifiëren JSON-correctheid, detecteren injectiepogingen in veldwaarden, blokkeren bekende exploitpatronen en monitoren anomalieën in payloadgroottes en aanroepfrequenties. WAF-configuratie voor API's vereist een andere aanpak dan voor traditionele webapplicaties — regels moeten rekening houden met de specificiteit van elk endpoint, toegestane datatypes en -groottes, en verwachte gebruikspatronen.
Monitoring en anomaliedetectie
Zelfs de best geconfigureerde API vereist continue monitoring. Anomaliedetectiesystemen leren normale gebruikspatronen — tijdstippen, typische aanroepsequenties, IP-adresverdeling — en alarmeren bij afwijkingen. Bijzonder waardevol is het monitoren van aanroepen die eindigen met 401- en 403-fouten (ongeautoriseerde toegangspogingen), ongewone responsgroottes (mogelijk datalek) en sequenties die resource-enumeratie suggereren.
ESKOM.AI ontwerpt API-beveiliging als ingebouwd element van de architectuur, niet als achteraf toegevoegde laag. Elke API die door het automatiseringssysteem wordt verkend, ondergaat een kwetsbaarheidsbeoordeling conform OWASP API Top 10 voordat deze in productie gaat.