Vad ett API-pentest faktiskt innebär

API-penetrationstestning är en kontrollerad, metodisk attack mot era API:er – genomförd med samma tekniker som verkliga angripare använder, men under kontrollerade former och med ert samtycke. Syftet är att avslöja sårbarheter i affärslogik, autentisering, auktorisering och datahantering.

Skillnaden mot webbapplikationspentest

API-typer och deras unika risker

Olika API-arkitekturer kräver olika testmetodik:

REST-API:er är vanligast och enklast att kartlägga via OpenAPI/Swagger-specifikationer – om de finns. Testfokus ligger på resursbaserad åtkomstkontroll, HTTP-metodfiltrering och parametervalidering.

GraphQL introducerar unika risker. Introspektionsfrågor avslöjar hela schemat om de inte stängts av. Djupt nästlade frågor kan orsaka denial-of-service. Batch-frågor kringgår ofta rate-limiting. Vi ser att en majoritet av GraphQL-implementationer i Sverige fortfarande har introspection aktiverat i produktion.

gRPC används alltmer i mikrotjänstarkitekturer. Protobuf-serialisering ger inte automatiskt säkerhet – samma logikbaserade sårbarheter existerar, men kräver specialiserade verktyg för testning.

WebSocket-API:er är ofta helt ignorerade i säkerhetstestning. Långlivade anslutningar utan per-meddelande-autentisering skapar möjligheter för session hijacking och injektionsattacker.

Testmetodik: Från rekognosering till rapport

Ett seriöst API-pentest följer en strukturerad metodik. Vi baserar vårt arbete på OWASP Testing Guide och PTES (Penetration Testing Execution Standard), anpassat för API-specifika utmaningar.

Fas 1: Rekognosering och kartläggning

Innan ett enda testanrop skickas kartlägger vi hela API-ytan:

• Dokumentationsanalys – Swagger/OpenAPI-specifikationer, Postman-collections, utvecklardokumentation
• Endpoint-discovery – Fuzzing efter odokumenterade endpoints (ofta /admin/, /internal/, /debug/-prefix)
• Versionsidentifiering – Äldre API-versioner (/v1/) som fortfarande är aktiva parallellt med nyare
• Autentiseringsflöden – OAuth 2.0-konfiguration, JWT-implementering, API-nyckelhantering

I vår erfarenhet hittar vi i genomsnitt 15–30 procent fler endpoints än vad som finns dokumenterat. Odokumenterade endpoints saknar nästan alltid fullständig säkerhetskonfiguration.

Fas 2: Autentiserings- och auktoriseringstestning

Den mest kritiska fasen. Här testar vi:

Token-säkerhet: Är JWT-signaturer korrekta? Accepterar API:et "alg": "none"? Kan vi ändra claims och fortfarande autentiseras? Hur hanteras token-förnyelse och revokering?

BOLA-testning (Broken Object Level Authorization): Systematisk testning av varje endpoint med resurs-ID:n som tillhör andra användare. Detta är den vanligaste kritiska sårbarheten i API:er enligt OWASP API Security Top 10, och den kräver manuell testning – automatiserade verktyg missar den nästan alltid.

Behörighetseskalering: Kan en vanlig användare anropa administrativa endpoints? Kan vi manipulera rollbaserade kontroller genom att injicera fält?

Autentiseringsbypass: Finns endpoints som helt saknar autentiseringskrav? Kan vi nå data genom att kringgå API-gatewayen direkt mot backend-tjänster?

Fas 3: Affärslogiktestning

Här skiljer sig ett bra pentest från en automatiserad skanning. Vi testar den logik som är unik för er applikation:

• Kan vi göra negativa transaktioner i ett betalnings-API?
• Kan vi använda en rabattkod flera gånger genom race conditions?
• Kan vi manipulera arbetsflödesordningen och hoppa över valideringssteg?
• Finns det TOCTOU-problem (time-of-check-to-time-of-use) i behörighetskontroller?

Dessa sårbarheter kan inte hittas med automatiserade verktyg. De kräver en testare som förstår er affärsdomän.

Fas 4: Injektions- och datatestning

Klassiska injektionsattacker anpassade för API-kontext:

• SQL/NoSQL-injektion via API-parametrar och JSON-fält
• Server-Side Request Forgery (SSRF) – speciellt relevant i molnmiljöer där interna metadata-API:er (169.254.169.254) kan nås
• XML External Entity (XXE) i SOAP-baserade API:er
• Dataexponeringsanalys – returnerar API:et mer data än klienten behöver?

Fas 5: Rapportering och åtgärdsplan

En rapport utan prioritering och konkreta åtgärdsförslag är värdelös. Varje fynd klassificeras enligt CVSS-ramverket och inkluderar:

• Exakt beskrivning av sårbarheten med reproducerbara steg
• Affärspåverkan – vad kan en angripare faktiskt åstadkomma?
• Rekommenderad åtgärd med kodexempel där möjligt
• Prioriteringsnivå baserad på exploaterbarhet och påverkan

Verktygskedjan: Vad vi faktiskt använder

Rätt verktyg för rätt uppgift – men verktyg ersätter aldrig expertis.

OWASP API Security Top 10: Vad vi ser i verkligheten

OWASP uppdaterade sin API Security Top 10 2023, och listan stämmer väl överens med vad vi observerar i våra tester. Här är de risker som träffar svenska organisationer hårdast:

API1: Broken Object Level Authorization (BOLA) – Överlägset vanligast. Vi hittar detta i majoriteten av alla pentest vi genomför. Grundproblemet är att API:et litar på att klienten skickar rätt resurs-ID utan att verifiera att användaren har behörighet.

API2: Broken Authentication – Svag JWT-konfiguration, avsaknad av token-rotation, API-nycklar hårdkodade i klientapplikationer.

API3: Broken Object Property Level Authorization – API:et returnerar hela objekt inklusive känsliga fält (lösenordshash, interna ID:n, personuppgifter) som klienten filtrerar bort i gränssnittet men som fortfarande finns i API-svaret.

API5: Broken Function Level Authorization – Administrativa endpoints skyddas bara genom att inte länkas i gränssnittet, inte genom faktisk behörighetskontroll.

Regulatoriska krav: NIS2, GDPR och ISO 27001

NIS2-direktivet

NIS2-direktivet, som är fullt implementerat i svensk lag, ställer explicita krav på att organisationer inom väsentliga och viktiga sektorer genomför regelbunden säkerhetstestning. API-pentest är ett direkt svar på kravet om "testning och granskning av säkerheten i nätverks- och informationssystem". Brott mot NIS2 kan leda till sanktionsavgifter upp till 10 miljoner EUR eller 2 procent av global omsättning.

GDPR – Artikel 32

GDPR artikel 32 kräver "ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten hos de tekniska och organisatoriska åtgärder som ska säkerställa behandlingens säkerhet." API-pentest är en direkt metod att uppfylla detta krav. Integritetsskyddsmyndigheten (IMY) har i tillsynsbeslut framhållit vikten av att testa system som behandlar personuppgifter.

ISO/IEC 27001

ISO 27001:2022, kontroll A.8.8 (Management of technical vulnerabilities), kräver att organisationer identifierar och hanterar tekniska sårbarheter. Regelbundna API-pentest stödjer direkt certifieringsprocessen och löpande efterlevnad.

Integrera API-testning i CI/CD

Manuella pentest är nödvändiga men otillräckliga som enda skydd. Mellan årliga eller kvartalsvisa pentest bör automatiserade API-säkerhetstester köras i er CI/CD-pipeline:

Steg 1: Exportera er OpenAPI-specifikation automatiskt vid varje build.

Steg 2: Kör OWASP ZAP eller Nuclei mot specifikationen i staging-miljö.

Steg 3: Skapa anpassade testfall för er affärslogik som körs som integrationstester.

Steg 4: Blockera deploy till produktion om kritiska sårbarheter hittas.

Steg 5: Aggregera resultat i er SIEM för trendanalys över tid.

Det här ersätter inte manuell testning – men det fångar regressioner och kända sårbarhetsmönster kontinuerligt. Managerad DevOps

Opsios perspektiv: Vad vi faktiskt ser

Från vår SOC/NOC i Karlstad och Bangalore övervakar vi API-trafik dygnet runt. Mönstren är tydliga:

Credential stuffing mot autentiserings-API:er är den vanligaste attacktypen vi blockerar. Angripare använder läckta lösenordslistor från dataintrång och automatiserar inloggningsförsök mot /api/auth/login-endpoints.

Automatiserad BOLA-scanning ökar kraftigt. Verktyg som systematiskt itererar genom resurs-ID:n för att hitta behörighetsbrister körs mot svenska organisationers API:er dagligen.

Shadow API:er – gamla API-versioner eller testmiljöer som fortfarande är nåbara från internet – är en återkommande källa till intrång. De saknar ofta uppdaterade säkerhetskontroller.

Vår rekommendation: kombinera kvartalsvis manuellt API-pentest med kontinuerlig automatiserad testning i CI/CD och dygnet-runt-övervakning från en SOC som förstår API-trafikmönster. Molnsäkerhet

Att välja rätt partner för API-pentest

Inte alla pentestleverantörer förstår API-specifika risker. Kontrollera följande:

• Erfarenhet av er API-typ – REST, GraphQL och gRPC kräver olika kompetens
• Manuell testning inkluderad – en rapport baserad enbart på automatiserade skanningar är otillräcklig
• OWASP-metodiken – testaren bör explicit följa OWASP API Security Top 10
• Åtgärdsverifiering – erbjuder leverantören retest efter att ni åtgärdat fynden?
• Förståelse för er regulatoriska kontext – NIS2, GDPR och branschspecifika krav

Managerade molntjänster

Vanliga frågor

Hur ofta bör man genomföra API-pentest?

Minst en gång per år för kritiska API:er, plus efter varje större arkitekturförändring. Organisationer under NIS2 bör testa kvartalsvis eller oftare. Komplettera med automatiserade skanningar i CI/CD-pipeline för löpande skydd mellan manuella tester.

Vad är skillnaden mellan API-pentest och vanlig webbapplikationspentest?

Ett API-pentest fokuserar på affärslogik, autentiseringsflöden, behörighetseskalering och dataexponering i maskin-till-maskin-kommunikation – snarare än gränssnittsbaserade sårbarheter som XSS i webbläsaren. API:er saknar ofta det visuella gränssnittets inbyggda begränsningar, vilket gör dem mer utsatta.

Vilka verktyg används vid API-penetrationstestning?

Burp Suite Professional är branschstandard för manuell testning. OWASP ZAP fungerar som kostnadsfritt alternativ. Postman och Insomnia används för att mappa endpoints, medan Nuclei och ffuf hanterar automatiserade skanningar. För GraphQL är InQL och graphql-voyager viktiga komplement.

Räcker automatiserade API-skanningar för att uppfylla NIS2-kraven?

Nej. NIS2 kräver att organisationer genomför adekvata säkerhetstester anpassade efter riskprofilen. Automatiserade verktyg missar logikbaserade brister som BOLA och behörighetseskalering. En kombination av automatiserad och manuell testning krävs för att visa tillräcklig due diligence.

Vad kostar ett API-pentest?

Priset varierar kraftigt beroende på API:ets storlek och komplexitet. Ett begränsat REST-API med 20–30 endpoints kan testas för 50 000–100 000 SEK. Stora plattformar med GraphQL, WebSockets och mikroservicearkitektur hamnar ofta på 150 000–400 000 SEK. Löpande avtal med kvartalsvis testning ger normalt lägre styckpris.