Hvorfor API'er er særligt sårbare
Programmatiske grænseflader forbinder interne og eksterne systemer, behandler følsomme data og fungerer automatiseret — uden menneskelig validering ved hvert kald. Traditionelle netværksperimeterbeskyttelser er utilstrækkelige, når enhver autoriseret klient kan foretage tusindvis af forespørgsler pr. minut. OWASP API Security Top 10 dokumenterer tilbagevendende sårbarhedskategorier, hvoraf mange ikke skyldes kodefejl, men utilstrækkeligt sikkerhedsdesign på arkitekturniveau.
Autentificering og autorisation — fundamentet
OAuth2 med Authorization Code-flow og PKCE er guldstandarden for API'er tilgængelige via klientapplikationer. For server-til-server-kommunikation er Client Credentials-flowet med kortlivede adgangstokens passende. Kritiske fejl, der skal elimineres i designfasen, er: lagring af tokens i localStorage i stedet for flygtig hukommelse, manglende validering af tilladelsesomfang ved hvert kald, udeladelse af audience-feltverifikation i JWT-tokenet og brug af statiske API-nøgler uden rotationsmekanisme.
- Adgangstokens: maksimal levetid 15-60 minutter
- Opdateringstokens: lagret i sikre, httpOnly cookies eller sikker serverlagring
- API-nøglerotation: obligatorisk, automatiseret, uden nedetid
- Inspektion af hvert kald vedrørende tilladelsesomfang — ikke kun ved login
Rate limiting som beskyttelse mod misbrug
Begrænsning af antal kald pr. tidsenhed beskytter API'er mod flere trusselsklasser samtidigt: brute force-angreb på loginoplysninger, datascraping, DDoS-angreb rettet mod forretningslogik og utilsigtet overbelastning fra defekte klienter. Effektiv rate limiting kræver granularitet — forskellige grænser for uautentificerede forespørgsler, autentificerede brugere og partnere med forhøjet tillid. Grænser bør anvendes på IP-adresse, bruger-ID og API-nøgle kombineret.
Det er vigtigt at være opmærksom på korrekt fejlkodning — kode 429 Too Many Requests bør indeholde Retry-After-header, hvilket muliggør korrekt klientadfærd og reducerer antal genforsøg. Alt for restriktive grænser skaber frustration hos brugerne og vanskeliggør problemdiagnosticering.
WAF og API-trafikinspektion
Næste generations Web Application Firewalls forstår API-strukturen — de verificerer JSON-korrekthed, detekterer injektionsforsøg i feltværdier, blokerer kendte exploitmønstre og overvåger anomalier i payload-størrelser og kaldsfrekvenser. WAF-konfiguration for API'er kræver en anden tilgang end for traditionelle webapplikationer — reglerne skal tage hensyn til hvert endpoints specificitet, tilladte datatyper og -størrelser samt forventede brugsmønstre.
Overvågning og anomalidetektion
Selv den bedst konfigurerede API kræver kontinuerlig overvågning. Anomalidetektionssystemer lærer normale brugsmønstre — tidspunkter, typiske kaldssekvenser, IP-adressefordeling — og alarmerer ved afvigelser. Særligt værdifuldt er at overvåge kald, der ender med 401- og 403-fejl (uautoriserede adgangsforsøg), usædvanlige svarstørrelser (potentielt datalæk) og sekvenser, der antyder ressourceenumeration.
ESKOM.AI designer API-sikkerhed som et indbygget arkitekturelement, ikke som et efterfølgende lag. Enhver API udforsket af automatiseringssystemet gennemgår en sårbarhedsvurdering i henhold til OWASP API Top 10 før produktionssætning.