OWASP API Security Top 10 i kundens krav

Spørger kunden, om jeres API er testet efter OWASP API Security Top 10, er det fristende at svare ja og gå videre. Men listen er ikke en teststandard med krav, der kan krydses af; den er en oversigt over typiske risici for API’er. Et præcist svar hviler derfor på to ting: hvad OWASP selv kalder listen, og hvad jeres test faktisk har afprøvet i jeres API. Svaret kan godt være kort, men det skal kunne forsvares, hvis kundens sikkerhedsfolk spørger ind.

Hvad listen er

OWASP API Security Project er et projekt under OWASP, der ifølge projektet selv skal imødegå det voksende antal organisationer, der udstiller potentielt følsomme API’er. Projektets mest kendte resultat er en top 10 over sikkerhedsrisici for API’er. Den seneste udgave er fra 2023 og afløste udgaven fra 2019.

Listen er en særskilt liste ved siden af OWASP’s generelle top 10 for webapplikationer. Den findes, fordi API’er har deres egne typiske svagheder, især i kontrollen af, hvem der må se og ændre hvilke data. Den generelle liste og dens brug er beskrevet på penetrationstest.dk. For et softwarehus er API-listen den mere præcise henvisning, når det er produktets API, kunden spørger til. → Produktets API

De ti kategorier i korte træk

Kategorierne i 2023-udgaven handler om fire hovedemner. Flere af dem gælder adgangskontrol: om en bruger kun kan nå de objekter, egenskaber og funktioner, brugeren har ret til. En gælder autentificering. To gælder misbrug af ressourcer og forretningsgange, som når en funktion kan bruges i et omfang eller en rækkefølge, den ikke var tænkt til. Og resten gælder opsætning, overblik over hvilke API-versioner og værter der kører, forespørgsler, som API’et sender videre på andres vegne, og den tillid, jeres API viser over for andre API’er, det henter data fra.

For et SaaS-produkt med flere kunder i samme løsning er adgangskategorierne de mest nærliggende at spørge til, fordi en fejl dér kan give én kunde adgang til en andens data. → Multi-tenant: test af adskillelsen

Hvad kunden spørger om

Et spørgsmål om OWASP API Security Top 10 kan dække flere ønsker. Kunden kan ville vide, om API’et overhovedet var med i testen. Kunden kan ville vide, om testeren har haft adgangskontrollen mellem kunder for øje. Eller kunden kan have kopieret formuleringen fra en skabelon uden at have et bestemt ønske.

Spørg derfor, hvad kunden skal bruge svaret til, hvis formuleringen er uklar. Et skema med et ja/nej-felt kan besvares med et delvist svar og en kommentar, der siger, hvad testen omfattede. → Ja, nej eller delvist

Et svar, der kan holde

Et godt svar har tre dele. Først: hvilken del af API’et testen dækkede, med version og dato. Dernæst: at testeren har haft kategorierne i API-listen for øje, hvis det er tilfældet, og hvilken udgave af listen der er tale om. Til sidst: hvad status er på de fund, der blev gjort.

Undgå formuleringen, at API’et opfylder listen eller er fri for de ti risici. Listen indeholder ikke krav, der kan opfyldes, og ingen test kan vise, at en kategori af svagheder slet ikke findes. Skriv i stedet, at testen har omfattet de risici, listen beskriver, i det omfang, der var aftalt. → Udokumenterede svar

Står listen i et kontraktudkast og ikke kun i et skema, er der mere på spil. En formulering om, at API’et skal være testet for alle ti risici hvert år, er til at leve med, hvis den passer til jeres testrytme. En formulering om, at API’et ikke må indeholde svagheder i nogen af kategorierne, kan ingen leverandør opfylde. Foreslå i stedet, at testen omfatter de risici, listen beskriver, og at fund behandles efter jeres aftalte frister. Angiv også udgaven, så kravet ikke ændrer sig, når OWASP udgiver en ny liste.

Hvad rapporten bør vise

Hvis kunderne jævnligt henviser til listen, kan I bede testeren om at knytte hvert fund til en kategori i 2023-udgaven, hvor det giver mening. Det gør det let for kunden at se, hvilke typer af svagheder testen fandt, og hvilke kategorier der ikke gav fund.

Bed også om, at omfangsafsnittet nævner, hvilke dele af API’et der var med: offentlige endepunkter, endepunkter for integrationer, administrative funktioner og ældre versioner, der stadig svarer. Netop den sidste gruppe hører til en af kategorierne på listen, og den bliver nemt glemt, når et softwarehus kun tester den nyeste version. → Omfangsafsnittet i rapporten

Et tænkt eksempel

Et softwarehus leverer et lagerstyringssystem med et API, som kundernes webshops bruger til at hente lagerstatus. En ny kunde skriver i sit spørgeskema: Er API’et testet efter OWASP API Security Top 10?

Softwarehuset svarer, at API’et version 3 var med i forårets penetrationstest, at testeren havde 2023-udgaven af listen for øje, og at fundene er knyttet til kategorierne i kundeversionen af rapporten. Et fund om adgangskontrol mellem webshops er rettet og efterprøvet. Softwarehuset tilføjer, at version 2 af API’et stadig svarer for to kunder, og at den ikke var med i testen. Kunden spørger, hvornår version 2 lukkes, og får en dato. Softwarehuset noterer svaret i sit svarbibliotek, så næste kunde med samme spørgsmål får samme formulering.

Det skal I lade være med

Skrive, at API’et opfylder listen · listen er en oversigt over risici, ikke krav.
Nævne listen uden udgave · 2019 og 2023 er forskellige.
Svare for hele API’et, når kun en del var testet · omfanget afgør svaret.
Glemme ældre versioner, der stadig svarer · de hører også til produktets API.
Forveksle API-listen med den generelle top 10 · det er to forskellige lister.

Hvad kan og ikke kan konkluderes

En test, der har haft API-listen for øje, kan vise, hvilke af de beskrevne risici testeren fandt i den del af API’et, der var med. Den kan ikke vise, at API’et er uden svagheder i nogen kategori, og den siger intet om de dele af API’et, der lå uden for omfanget. En henvisning til listen gør svaret lettere at forstå, men erstatter ikke en beskrivelse af, hvad der faktisk blev testet.