Produktets API: det, kundernes integrationer bygger på

Kunder, der kobler deres egne systemer på produktet via API’et, gør API’et til en del af deres egen drift. Svaret på, om det skal med i pentesten, hviler på et enkelt forhold: alt, hvad en bruger kan gøre i brugerfladen, kan typisk også gøres gennem API’et, og måske mere. En test, der kun ser på skærmbillederne, dækker ikke den dør, kundernes data kan gå ud og ind ad.

For et softwarehus er der en ekstra pointe. API’et er en aftale med kunderne. Når testen finder noget, kan rettelsen påvirke de integrationer, kunderne selv har bygget.

API’et er produktet uden skærm

En brugerflade viser kun det, den er bygget til at vise. API’et tager imod de forespørgsler, det får, og det er API’et, der skal afgøre, om den, der spørger, må få svar. Hvis kontrollerne kun sidder i brugerfladen, holder de ikke, når nogen taler direkte med API’et.

OWASP har en særskilt liste over de mest udbredte sikkerhedsrisici for API’er, fordi API’er har deres egne typiske svagheder, bl.a. i kontrollen af, hvem der må nå hvilke data og funktioner. Nogle kunder bruger listen som reference, når de spørger, hvad testen har dækket. → OWASP API Security Top 10 i kundens krav

Køberens side af API-testen er beskrevet generelt på penetrationtest.dk. Her er vinklen jeres: API’et som en del af det produkt, I sælger, og som kunderne har bygget deres egne arbejdsgange oven på.

Hvorfor kunderne spørger til API’et

Kundens sikkerhedsansvarlige ser API’et som en vej ind i deres egne data, der ikke går gennem en person. Spørgsmålene kan være:

Adgang · hvordan får en integration adgang, og hvem udsteder nøglerne?
Rettigheder · kan en nøgle begrænses til bestemte data eller handlinger?
Adskillelse · kan en integration hos én kunde nå en anden kundes data?
Overblik · kan kunden se, hvilke integrationer der har adgang, og lukke dem igen?
Dokumentation · var API’et med i jeres seneste test?

Det sidste spørgsmål er det, rapporten skal kunne besvare direkte. Hvis API’et ikke står i omfanget, er svaret nej, uanset hvor grundigt resten af produktet blev testet.

Spørgsmålene kan komme fra kundens integrationsfolk og ikke kun fra sikkerhedsfunktionen. De skal bygge og drive forbindelsen, og de vil vide, om de kan regne med, at en nøgle med læseadgang kun giver læseadgang. Et klart svar, der henviser til et bestemt afsnit i rapporten, sparer jer for mange mails frem og tilbage. Det gør det også lettere for kunden at forklare egen ledelse, hvorfor integrationen er i orden.

Hvad testen afprøver i API’et

Testen af API’et ser på de samme grænser som resten af produktet, men fra en anden side:

Grænsen mellem kunderne · kan en integration hos én kunde hente eller ændre data hos en anden? → Multi-tenant: test af adskillelsen mellem kunderne
Grænsen mellem roller · giver en nøgle med begrænsede rettigheder kun adgang til det, den skal?
Grænsen mellem versioner · gælder samme kontrol i ældre versioner af API’et, som stadig er tilgængelige?
Grænsen for mængder · kan API’et bruges til at hente langt mere data end tilsigtet på kort tid?

Testen afprøver også, om fejlbeskeder og svar fra API’et afslører mere, end en integration har brug for. Det er alt sammen beskrevet på begrebsniveau i omfanget; den præcise fremgangsmåde er testerens. → Roller og rettigheder i produktet

Det, I skal give testeren

En API-test går hurtigere og dækker mere, når testeren ikke skal gætte sig til, hvad API’et kan. Giv testeren:

Dokumentationen · den, kunderne bruger, og gerne en intern, hvis den er mere fuldstændig.
Nøgler med forskellige rettigheder · hos mindst to testlejere, så både roller og adskillelse kan afprøves.
En liste over versioner · hvilke der er aktive, og hvilke kunder der stadig bruger dem.
Grænser for belastning · hvad testeren må, så testen ikke påvirker andre kunder.

Hvis API’et også er åbent for udviklere hos kunder og partnere gennem en portal, hører portalen med som et emne for sig. → Offentligt API og udviklerportal

Versioner, som kunderne stadig bruger

Et API lever længe. Kunder bygger integrationer, der kører i årevis, og en ældre version kan blive holdt åben af hensyn til dem. Den gamle version kan mangle kontroller, som er tilføjet i den nye, og den kan være glemt i den interne oversigt.

Aftal, hvilke versioner der er med i testen, og skriv det i rapporten. Kunder, der stadig bruger en ældre version, vil spørge, om netop den blev testet. → En gammel version, der stadig har kunder

Når en rettelse ændrer API’ets adfærd

Et fund i API’et skal rettes som alle andre fund, men rettelsen kan bryde noget hos kunderne. Hvis en nøgle tidligere kunne mere end tilsigtet, vil nogle integrationer have bygget på det. Når rettelsen lukker for det, holder integrationen op med at virke.

Planlæg derfor rettelser i API’et sammen med kommunikationen til kunderne. Nogle rettelser kan ikke vente, og så må kunderne have besked samtidig med eller kort efter. Andre kan varsles, så kunderne kan nå at tilpasse sig. → Sikkerhedsmeddelelse til kunderne om en sårbarhed

Det skal I lade være med

Teste brugerfladen og regne API’et for dækket · API’et har sine egne kontroller, eller mangel på samme.
Give testeren én nøgle med alle rettigheder · så kan grænserne mellem rettigheder ikke afprøves.
Glemme de ældre versioner · de kan være dem, kunderne stadig er afhængige af.
Skjule API’et for testeren for at se, om det findes · det bruger testtiden på det forkerte.
Rette fund i API’et uden at tænke på integrationerne · en rettelse uden varsel kan stoppe kundernes drift.
Skrive i salget, at API’et er testet, uden at angive versionen · kunderne bruger forskellige versioner.

Hvad kan og ikke kan konkluderes

En test uden alvorlige fund i API’et viser, at testeren ikke kunne overskride grænserne for de versioner, nøgler og roller, der var med. Den siger ikke noget om versioner uden for omfanget, om nye endepunkter efter testen eller om, hvordan kunderne selv opbevarer deres nøgler.

Tjekliste til API’et i testen

☐ Står API’et som en selvstændig del af omfanget?
☐ Har testeren dokumentation og nøgler med forskellige rettigheder?
☐ Har testeren nøgler hos mindst to testlejere?
☐ Er det aftalt, hvilke versioner der testes?
☐ Er grænser for belastning aftalt?
☐ Er der en plan for, hvordan rettelser varsles over for kunderne?

Kilder

OWASP API Security Project: oversigt over de mest udbredte sikkerhedsrisici for API’er, herunder adgangskontrol til data og funktioner.
NCSC (UK): Principle 11, External interface protection: API’er som eksterne grænseflader i en cloudtjeneste, der skal identificeres og beskyttes.

Senest gennemgået: oktober 2026.