API-sikkerhed

API-sikkerhed adskiller sig fra klassisk websikkerhed, fordi et API eksponerer applikationens objektmodel direkte: id'er, feltnavne og operationer kommer ind som strukturerede parametre, som en klient kan gennemløbe og afspille igen i maskintempo, uden en brugerflade, der skjuler noget. OWASP API Security Top 10 (2023) afspejler det. Første punkt, API1 Broken Object Level Authorization (BOLA, API-verdenens navn for IDOR), er situationen, hvor serveren autentificerer kalderen, men aldrig tjekker, at objekt-id'et i stien eller body'en tilhører vedkommende. API3 Broken Object Property Level Authorization dækker både overeksponering af data (hele rækken returneres, og klienten filtrerer) og mass assignment (en indkommende JSON-body bindes direkte på en model, så kalderen kan sætte felter som isAdmin eller ownerId). API5 Broken Function Level Authorization er samme fejl et niveau op, fx en almindelig bruger, der kalder et administrativt DELETE-endpoint.

Autentificering af maskinklienter sker typisk med OAuth 2.0-access tokens, ofte JWT'er, eller med gensidig TLS. Klassiske fejl er at acceptere usignerede tokens (alg none), ikke at validere aud, iss og exp, at forveksle RS256 med HS256, så en offentlig nøgle bruges som HMAC-hemmelighed, og langlivede bearer tokens uden binding til klienten. Afsenderbundne tokens (mTLS-bundne efter RFC 8705 eller DPoP efter RFC 9449) gør et stjålet token mindre værd. En API-nøgle identificerer en klientapplikation; alene autentificerer den ikke en bruger.

Ressourcekontroller rammer API4 Unrestricted Resource Consumption og API6 Unrestricted Access to Sensitive Business Flows: rate limits pr. identitet frem for pr. IP-adresse, maksimal sidestørrelse, grænser for body-størrelse, timeouts og for GraphQL grænser for forespørgselsdybde og -omkostning samt slået introspection fra i produktion. API9 Improper Inventory Management er problemet med skygge- og zombie-API'er: gamle versioner som /v1, der stadig kan nås uden de rettelser, der er lavet i /v2. En OpenAPI-beskrivelse, der vedligeholdes i build-pipelinen, giver både et inventar og et skema, som en gateway kan håndhæve.

En API-gateway eller WAF er god til grove kontroller (TLS-terminering, tokenvalidering, kvoter, skematjek), men den kan ikke vide, om bruger 17 ejer faktura 4711. Autorisation på objektniveau skal derfor ligge i selve tjenesten, helst i ét centralt politiklag, og den skal testes med to konti, fordi scannere med én identitet sjældent finder BOLA. NIST SP 800-228 beskriver de samme kontroller for cloud-native API'er mellem tjenester, hvor øst-vest-trafik mellem microservices kræver autentificering lige så meget som den offentlige kant.