Offentligt API og udviklerportal: hvad skal med i testen?

En udviklerportal er der, hvor kunder, partnere og ukendte udviklere selv kan læse dokumentationen, oprette en konto og få nøgler til jeres API. Svaret på, hvad testen skal dække, hviler på den forskel: portalen er åben for folk, I ikke har indgået aftale med, så alt, hvad den udleverer, skal kunne tåle at blive brugt af nogen med dårlige hensigter. Testen skal derfor omfatte selve portalen, ikke kun det API, den giver adgang til.

Det API, kundernes integrationer bygger på, er et emne for sig. Her handler det om døren til det: tilmeldingen, nøglerne, sandkassen og dokumentationen. → Produktets API: det, kundernes integrationer bygger på

Portalen åbner produktet for folk, I ikke kender

Et lukket API bruges af kunder, I har kontrakt med. Et offentligt API med selvbetjening bruges af alle, der har oprettet en konto. Det ændrer, hvem der står på den anden side, og dermed hvilke spørgsmål testen skal stille.

For kundernes sikkerhedsfolk er portalen et tegn på, hvor mange veje der findes ind i produktet. De vil vide, om en fremmed med en udviklerkonto kan komme tættere på deres data, end en fremmed uden konto kan. Rapporten skal kunne svare på det.

Selvbetjening rejser også et forretningsspørgsmål, som testen ikke kan afgøre for jer: hvad må en udviklerkonto uden nogen aftale? Hvis enhver kan oprette en konto og straks hente data fra en sandkasse eller kalde API’et uden begrænsning, er det et valg, I har truffet. Testen kan vise, om de grænser, I har sat, holder. Den kan ikke sætte grænserne.

Hvad der hører til en udviklerportal

Portaler ser forskellige ud, men disse dele kan gå igen:

Tilmelding · hvordan en udvikler opretter en konto, og hvad der kontrolleres.
Nøgler og applikationer · hvordan nøgler udstedes, begrænses, fornyes og trækkes tilbage.
Sandkasse · et miljø til at afprøve API’et uden rigtige data.
Dokumentation · beskrivelser, eksempler og maskinlæsbare specifikationer.
Forbindelse til kunderne · den mekanisme, hvor en kunde giver en partners applikation lov til at hente deres data.

Det sidste punkt er ofte det vigtigste. Det er her, en ukendt udviklers applikation får adgang til en rigtig kundes data, fordi kunden har sagt ja. Kunden ser kun en knap, der giver tilladelse. Bag den ligger en række kontroller, som afgør, hvor meget applikationen må, hos hvem og hvor længe. Det er dem, kundens sikkerhedsfolk regner med, at I har testet.

Hvad testen afprøver

Testen ser på portalen som en del af produktet og på de grænser, den skal holde:

Kontoen · kan en udviklerkonto bruges til mere end at udvikle, fx til at se andre udvikleres applikationer eller nøgler?
Nøglerne · gælder de begrænsninger, der vælges ved oprettelsen, også i praksis?
Tilbagetrækning · holder en nøgle op med at virke, når den trækkes tilbage, eller når en kunde fjerner sit samtykke?
Kundens samtykke · får en applikation kun adgang til det, kunden har sagt ja til, og kun hos den kunde?
Overgangen · kan noget fra sandkassen bruges mod produktionen?

Alle punkterne er beskrevet på begrebsniveau i omfanget. Testeren skal have konti som udvikler og som kunde for at kunne afprøve samtykket fra begge sider. → Testlejere

Aftal også, hvordan testeren må bruge tilmeldingen. Må testeren oprette nye udviklerkonti undervejs, og hvor mange? Skal de mærkes, så jeres support ikke tager dem for rigtige partnere? Og hvem skal have besked, hvis testen påvirker portalen for de udviklere, der bruger den i forvejen?

Sandkassen og produktionen

En sandkasse giver udviklere et sted at øve sig. Den er tænkt som ufarlig, men den kan blive en vej ind, hvis den deler noget med produktionen: brugere, nøgler, data eller infrastruktur. En sandkasse, der er sat op med en kopi af rigtige kundedata for at gøre den realistisk, er ikke længere ufarlig.

Aftal, om sandkassen er med i testen, og beskriv i rapporten, hvordan den er adskilt fra produktionen. Kunderne spørger måske ikke til sandkassen direkte, men de spørger, om der findes kopier af deres data andre steder end i produktionen.

Dokumentationen fortæller mere, end I tror

Offentlig dokumentation er en del af det, testeren ser på, fordi den er det første, enhver kan læse. OWASP peger på, at manglende eller forældet dokumentation og uklarhed om, hvilke versioner og værter der kører, er en kilde til svagheder i API’er. Dokumentationen kan nævne funktioner, der ikke skulle have været offentlige, eller beskrive gamle versioner, der stadig svarer.

Gennemgå selv dokumentationen, før testen starter. Fjern det, der ikke skal være offentligt, og notér de versioner, der stadig svarer. Så bruger testeren tiden på det, I ikke selv kan se.

For jer er det også et spørgsmål om overblik. Hvis dokumentationen og det, der faktisk kører, ikke stemmer overens, er det svært at svare præcist på, hvad testen har dækket. → En gammel version, der stadig har kunder

Portaler, som en anden leverandør driver

Nogle softwarehuse bruger en ekstern tjeneste til portalen eller til at styre nøgler og adgang. Det flytter ikke ansvaret over for kunderne. Hvis portalen ligger hos en anden, skal I afklare, hvad jeres test må omfatte, og hvad leverandøren selv dokumenterer.

Skriv i omfanget, hvilke dele der er jeres, og hvilke der drives af andre, så kunden kan se det. Kunder, der spørger til jeres underleverandører, vil også spørge til den, der udsteder nøglerne til jeres API. → Kunden spørger til hosting og underleverandører

Det skal I lade være med

Teste API’et og springe portalen over · tilmelding og nøgler er en del af angrebsfladen.
Lade testeren bruge en intern udviklerkonto · testen skal se det, en fremmed ser.
Fylde sandkassen med kopier af rigtige data · så er den ikke en sandkasse.
Glemme kundens samtykke · det er den mekanisme, der giver fremmede adgang til kundedata.
Lade gammel dokumentation ligge · den peger på versioner, der måske stadig svarer.
Udelade en ekstern portaltjeneste uden at skrive det · kunden skal kunne se grænsen.

Hvad kan og ikke kan konkluderes

En test af udviklerportalen viser, om tilmelding, nøgler, samtykke og sandkasse holdt de grænser, der var aftalt, i den testede version. Den siger ikke noget om, hvad udviklere gør med de nøgler, de lovligt har fået, eller om dele af portalen, der drives af en anden og ikke var med.

Tjekliste til udviklerportalen

☐ Står portal, tilmelding og nøgler i omfanget?
☐ Har testeren konti som både udvikler og kunde?
☐ Er kundens samtykke til partnerapplikationer med i testen?
☐ Er det beskrevet, hvordan sandkassen er adskilt fra produktionen?
☐ Stemmer den offentlige dokumentation med det, der kører?
☐ Er det klart, hvilke dele af portalen der drives af andre?

Kilder

OWASP API Security Top 10 2023: Improper Inventory Management: risici ved manglende eller forældet dokumentation, gamle versioner og uklarhed om, hvilke værter og versioner der kører.

Senest gennemgået: oktober 2026.