Et API, som ingen i IT-afdelingen kender, bliver ikke testet, ikke opdateret og ikke lukket, når det ikke bruges mere. Før en test, der omfatter API’er, er IT’s vigtigste bidrag derfor en liste: hvilke API’er findes der, hvor kører de, hvem bruger dem, og hvem ejer dem. Svaret hviler på et princip, som OWASP beskriver i sin liste over sikkerhedsrisici for API’er: manglende overblik over værter, versioner og miljøer er i sig selv en risiko, fordi glemte udgaver ofte er dårligere beskyttet end de aktuelle.
Køberens spørgsmål om, hvad en API-test er, og hvad der skal oplyses ved bestillingen, er forklaret på penetrationtest.dk. Overblikket over, hvad der findes, er derimod driftens opgave.
Hvor API’erne gemmer sig i driften
I en almindelig IT-afdeling findes API’er flere steder, end man umiddelbart tænker på:
- Webløsninger · kundeportaler og bookingsystemer, hvor skærmbillederne henter data gennem et API.
- Forretningssystemer · ERP, CRM og HR-systemer med indbyggede API’er til integrationer.
- Integrationsplatforme · servere eller tjenester, der flytter data mellem systemerne.
- Cloudtjenester · funktioner og API’er i Azure eller AWS, som et projekt har sat op. → Azure-test
- Udstyr · netværksudstyr, lagersystemer og driftsværktøjer med en programmeringsgrænseflade til administration.
- Interne værktøjer · små løsninger, som IT selv har bygget til automatisering. → Interne værktøjer bygget af IT selv
Mange af dem er ikke synlige som en hjemmeside. De opdages først, når nogen leder efter dem, eller når en tester gør det.
Det, listen skal indeholde
OWASP anbefaler at registrere hver vært med miljø, målgruppe og version, og hver integration med formål og de data, der udveksles. Omsat til IT-afdelingens hverdag kan listen have disse felter:
- Navn og adresse · hvor API’et kan nås.
- Miljø · produktion, test eller udvikling.
- Målgruppe · offentligt, kun internt eller kun for bestemte partnere.
- Version · hvilke udgaver der kører samtidig.
- Ejer · hvem i forretningen og hvem i IT der har ansvaret.
- Brugere · hvilke systemer, partnere og programmer der kalder API’et.
- Data · hvad der udveksles, og hvor følsomt det er.
- Login · hvordan kalderen identificerer sig, fx med en nøgle, et certifikat eller en konto.
Listen behøver ikke være perfekt for at være nyttig. Selv en ufuldstændig oversigt giver testeren et udgangspunkt og jer et sted at notere det, testen finder.
Ejerskab, før testen starter
Et API uden ejer er et problem allerede før testen. Hvis testeren finder noget, skal fundet have en modtager. Gå listen igennem og find en ansvarlig for hvert punkt. Hvis ingen vil kendes ved et API, er det et tegn på, at det måske kan lukkes.
Ejerskabet kan være delt. Leverandøren af et forretningssystem ejer koden bag API’et, mens IT ejer opsætningen, adgangen og nøglerne. Fordelingen er beskrevet for købte webløsninger generelt. → Webløsninger, som IT drifter, men ikke har udviklet
Gamle versioner og glemte miljøer
Når et API får en ny version, kan den gamle blive ved med at køre, fordi en partner eller et ældre system stadig bruger den. Det samme gælder test- og udviklingsudgaver, der blev sat op til et projekt og aldrig lukket. OWASP peger på, at sådanne udgaver kan mangle de forbedringer, der er lavet i den aktuelle version.
For IT-afdelingen er spørgsmålene enkle: hvem bruger stadig den gamle version, hvornår kan de flytte, og hvad gør vi indtil da? Hvor den gamle version skal leve videre, skal den have samme beskyttelse som den nye. Test- og udviklingsudgaver med rigtige data skal beskyttes som produktion. → Testmiljø til webtesten
Hvad testen kan tilføje
En test kan supplere jeres liste. Testeren kan se, hvilke API’er der svarer udefra, og hvilke versioner der er tilgængelige. Fund af den type er ikke nødvendigvis alvorlige svagheder, men de er nyttige oplysninger om, hvor jeres overblik ikke holdt.
Testen afprøver desuden for hvert API, der er med i aftalen, om adgangskontrollen holder, om API’et afslører mere, end kalderen har brug for, og om nøgler og konti har passende rettigheder. → API-nøgler og integrationskonti
Når testen finder et API, der ikke stod på listen, skal det ind på listen, også selvom det ikke blev testet i dybden. Ellers er det glemt igen ved næste test.
Listen skal leve efter testen
En oversigt, der kun bliver opdateret op til en test, er forældet det meste af året. Knyt den i stedet til de processer, der allerede findes i driften. Når et nyt system sættes i drift, eller en ny partner kobles på, er registreringen af API’et en del af opgaven. Når en integration lukkes, fjernes den fra listen, og nøglerne spærres.
Ændringsstyringen er det naturlige sted at fange det. Et ændringsforslag, der åbner et API mod internettet eller giver en ny partner adgang, bør ikke kunne godkendes, før listen er opdateret og en ejer er udpeget. → Testen i jeres ændringsstyring
Gennemgå desuden listen med faste mellemrum sammen med ejerne. Spørg for hvert punkt, om API’et stadig bruges, om målgruppen er den samme, og om der er kommet nye kaldere til. Det tager kort tid, når listen er holdt ved lige, og det gør forberedelsen til næste test langt lettere.
Det skal I lade være med
- At give testeren en liste, I ved, er ufuldstændig, uden at sige det. Så tror alle, at dækningen er bedre, end den er.
- At lade gamle versioner køre uden ejer. De får ingen opdateringer, og ingen opdager, hvis de bliver misbrugt.
- At gemme listen et sted, kun én kender. Den skal kunne bruges, når den person er på ferie.
- At udelade interne API’er. Et internt API kan nås af alle, der har fået fodfæste på det interne net.
- At glemme API’er i udstyr og driftsværktøjer. De kan have de bredeste rettigheder. → Driftsværktøjer med bred adgang
Hvad kan og ikke kan konkluderes
En test viser, hvordan de API’er, der var omfattet, holdt på testtidspunktet, og kan pege på API’er, der svarede uden at stå på listen. Den kan ikke garantere, at der ikke findes andre API’er, fx bag et login, på det interne net eller hos en leverandør. Overblikket er IT’s opgave og skal holdes ved lige mellem testene.
Tjekliste til API-listen
- ☐ Er alle kendte API’er registreret med adresse, miljø og målgruppe?
- ☐ Har hvert API en ejer i forretningen og i IT?
- ☐ Er det noteret, hvem der kalder hvert API, og hvilke data der udveksles?
- ☐ Er gamle versioner registreret med en plan for udfasning?
- ☐ Er test- og udviklingsudgaver med rigtige data beskyttet som produktion?
- ☐ Er API’er, testen fandt, tilføjet listen?
Kilder
- OWASP API Security Top 10 2023: API9 Improper Inventory Management: risikoen ved manglende overblik over værter, versioner og miljøer; registrering af miljø, målgruppe og version; registrering af integrationer og data; beskyttelse af alle udgaver; udfasning af gamle versioner.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Testmiljø til webtesten · Filoverførsel og partnerudveksling
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
