API‑test forklaret for købere: hvad skal I oplyse om jeres API’er?

Et API er en indgang til et system, som andre programmer bruger i stedet for mennesker. Hvad en test af API’et kan vise, afhænger næsten helt af, hvad køberen oplyser: hvilke API’er der findes, hvem der bruger dem, hvilke versioner der er i drift, og hvilke adgange testeren får til dem.

Uden de oplysninger kan testeren kun undersøge det, der kan findes udefra, og det er ofte en lille del. Med dem kan testen gå målrettet efter de spørgsmål, der betyder mest for virksomheden, især om API’et kun udleverer det, den enkelte bruger har ret til.

En indgang uden skærmbilleder

En kundeportal har sider, som brugeren klikker rundt på. Bag siderne ligger ofte et API, som portalen bruger til at hente og gemme oplysninger. Det samme API kan også bruges af partnere eller af andre systemer i virksomheden. Brugeren ser det ikke, men det er der.

Det har to konsekvenser for bestillingen. For det første kan en test, der kun ser på portalens sider, overse API-funktioner, som siderne ikke bruger. For det andet kræver en test af API’et oplysninger, som ikke kan aflæses af skærmen. Den bredere bestilling af webløsninger er beskrevet i → Penetrationstest af webapplikationer.

OWASPs projekt om API-sikkerhed behandler API’er som et selvstændigt område og har en egen liste over de mest udbredte risici. Listen fra 2023 nævner blandt andet adgangskontrol til de enkelte oplysninger, autentifikation og manglende overblik over, hvilke API’er og versioner der er i drift. For køberen er de tre punkter et godt udgangspunkt for at stille spørgsmål til sin egen løsning.

Hvem bruger API’et?

Start med at beskrive brugerne. Det afgør, hvilke spørgsmål testen skal besvare.

Egen webløsning · API’et bruges kun af webshoppen eller kundeportalen.
Partnere · forhandlere, leverandører eller kunder kobler deres egne systemer på.
Interne systemer · ERP-systemet og andre løsninger udveksler oplysninger gennem API’et.
Offentlig adgang · API’et er åbent for udviklere, der registrerer sig.

Et API, som partnere bruger, har en anden udsathed end et, der kun bruges internt. Hvis API’et er ved at blive åbnet for partnere, er tidspunktet for testen et emne for sig. → Et API åbnes for partnere

Det, testeren skal have udleveret

En API-test bliver langt mere præcis, når testeren får beskrivelsen af API’et. Et API er ofte beskrevet i en dokumentation over funktionerne og de oplysninger, de modtager og sender. Den dokumentation er nøglen til en målrettet test.

Dokumentation · beskrivelsen af API’ets funktioner, gerne den samme, som udviklere eller partnere bruger.
Adgange · nøgler eller konti, som svarer til de brugertyper, der skal vurderes.
Roller · en forklaring af, hvad hver brugertype må hente og ændre.
Miljø · adressen på det miljø, der skal testes, og forskelle fra driften.

Det svarer til forskellen mellem en test uden og med forhåndsviden. En API-test uden dokumentation kan have sit eget formål, men den giver et andet og ofte smallere svar. → Black box, grey box og white box

Adgangene skal behandles som rigtige adgange. Aftal, hvordan de udleveres, hvor længe de gælder, og hvordan de lukkes efter testen. → Testkonti og testdata

Rettigheder i API’et

Det vigtigste spørgsmål ved mange API’er er, om de kun udleverer det, den enkelte bruger har ret til. Et API, der henter ordrer, skal kun udlevere den aktuelle kundes ordrer. Et API, som partnere bruger, skal kun give hver partner adgang til egne oplysninger.

For at undersøge det skal testeren have adgange til mindst to brugere eller partnere, så det er muligt at se, om den ene kan nå den andens oplysninger. Det er samme princip som for kundeportalen, og det er beskrevet nærmere i → Kunders oplysninger skal holdes adskilt.

Skeln også mellem at læse og at ændre. Et API, der lader en bruger se for meget, er alvorligt. Et API, der lader en bruger ændre andres oplysninger eller udføre handlinger, brugeren ikke må, kan være mere alvorligt. Beskriv, hvilke funktioner der ændrer noget, så de kan prioriteres.

Versioner og glemte API’er

API’er udvikler sig. En ny version kommer til, men den gamle får lov at køre videre, fordi en partner endnu ikke er flyttet. Et testmiljø med et API bliver liggende på internettet efter projektet. Sådanne glemte indgange har ofte ældre regler end den version, alle tror er i brug.

Lav en oversigt over de API’er og versioner, der er i drift, og angiv, hvilke der skal med. Hvis virksomheden ikke har det overblik, er det i sig selv et fund at tage med internt. Bed om, at rapporten nævner, hvilke versioner der blev undersøgt.

API’er, der forbinder virksomhedens egne systemer, hører også med i overblikket, selv om de ikke er synlige udefra. → Integrationer mellem systemer

Belastning og drift

Et API kan blive belastet, hvis det modtager mange forespørgsler på kort tid. Det kan være en del af testens spørgsmål, om API’et har grænser for brug. Det er samtidig en risiko for driften, hvis API’et bruges af partnere eller af webshoppen i åbningstiden.

Aftal, om belastning er en del af opgaven, og i givet fald hvordan og hvornår. Overvej, om testen skal ske i et testmiljø, der svarer til driften. Et testmiljø, der afviger fra driften, giver et svar om testmiljøet. → Penetrationstest i produktion eller testmiljø

Det skal I lade være med

At gå ud fra, at test af portalen dækker API’et. API’et kan have funktioner, som siderne ikke bruger.
At holde dokumentationen tilbage. Uden den bliver testen bredere og mindre præcis.
At teste med én bruger. Rettigheder mellem brugere kræver mindst to adgange.
At glemme gamle versioner. De kører ofte videre med ældre regler.
At overse belastning. Aftal, om og hvordan grænserne for brug må afprøves.

Hvad kan og ikke kan konkluderes

En API-test kan vise, hvordan de undersøgte funktioner og versioner opførte sig med de udleverede adgange i det miljø, der blev testet. Den kan ikke sige noget om versioner, funktioner eller brugertyper, der ikke var med.

Et resultat uden fund er mest værdifuldt, når rapporten tydeligt viser, hvilke API’er, versioner og roller der indgik. Uden den oplysning kan en partner eller kunde ikke vurdere, om resultatet dækker den del af API’et, de selv bruger.