Een API pentest test de koppelingen achter je applicatie: de laag waarmee schermen, mobiele apps en partnersystemen gegevens ophalen en wegschrijven. Die laag is niet voor mensen bedoeld, dus kijkt niemand ernaar. Aanvallers wel. In scopegesprekken blijkt een API die zonder controle gegevens teruggeeft een van de meest voorkomende bevindingen bij organisaties die er nooit naar keken.
Kort samengevat
- API’s zijn de laag achter je schermen; ze bieden vaak meer aan dan de schermen laten zien.
- Een gewone webtest raakt alleen de API’s die de browser gebruikt; een API pentest benadert ze direct.
- De meest voorkomende bevinding is ontbrekende autorisatie: gegevens van een ander door een nummer aan te passen.
- Vraag altijd expliciet of API’s in de scope zitten; standaard vallen ze er vaak buiten.
Als een organisatie een “externe pentest” of een “webapplicatietest” koopt, denkt ze dat de applicatie is getest. Dat is deels waar. Getest is wat een gebruiker ziet en doet. Wat een aanvaller ziet, is iets anders: de koppelingen die de applicatie achter de schermen aanroept, en die vaak veel meer kunnen dan de knoppen op het scherm.
Waarom zijn API’s kwetsbaarder dan schermen?
Drie redenen die in vrijwel elke API pentest terugkomen:
- Ze zijn niet zichtbaar, dus niet bekeken. Een scherm wordt door ontwerpers, testers en gebruikers dagelijks gezien. Een API wordt gebouwd, werkt, en verdwijnt uit het zicht. Fouten erin worden niet toevallig opgemerkt.
- Ze vertrouwen op de voorkant. Een scherm toont alleen de knoppen die bij jouw rol horen. De API erachter gaat er te vaak van uit dat alleen die knoppen hem aanroepen, en controleert zelf niet meer wie er aanklopt. Wie de API direct benadert, ziet de knoppen niet en heeft ze ook niet nodig.
- Ze stapelen zich op. Een oude versie die blijft draaien voor een app die nog ergens in gebruik is. Een koppeling voor een partner die niet meer bestaat. Een testfunctie die nooit is uitgezet. Elke API die je hebt gebouwd, is er meestal nog.
Wat vindt een API pentest?
De tester benadert de koppelingen direct, zoals een aanvaller dat doet, en werkt een vaste reeks af:
- Autorisatie per object. Krijg ik met mijn account gegevens van een ander terug als ik een identificatienummer aanpas? Dit is de meest voorkomende en meest schadelijke fout, en hij zit in verrassend veel applicaties.
- Autorisatie per functie. Kan een gewone gebruiker een functie aanroepen die voor beheerders is bedoeld, gewoon omdat de knop ontbreekt maar de API bestaat?
- Authenticatie. Zijn er API’s die zonder inlog bereikbaar zijn en toch gegevens teruggeven? Vaak per ongeluk: een statusfunctie, een zoekfunctie, een exportfunctie.
- Te veel gegevens. Geeft de API meer terug dan het scherm toont? Een profiel-API die ook het e-mailadres, het telefoonnummer en de interne notities meestuurt omdat het scherm ze toch niet laat zien.
- Oude en vergeten versies. Draait er naast de huidige API nog een vorige, met de fouten die in de nieuwe zijn opgelost?
- Limieten. Kan de API onbeperkt worden aangeroepen, bijvoorbeeld om wachtwoorden te raden of om gegevens in bulk op te halen?
Waarom valt dit buiten een standaard pentest?
Omdat een webapplicatietest volgt wat de browser doet. De tester klikt, en test wat er dan gebeurt. De API’s die daarbij worden aangeroepen, worden meegetest; alles wat de schermen niet gebruiken, blijft buiten beeld. In offertes staat daarom regelmatig “webapplicatie” zonder dat de API’s expliciet zijn genoemd, en dan is de kans groot dat ze niet gericht zijn getest. Vraag het na. Een aanbieder die het verschil kent, noemt de API pentest als aparte scope of als expliciet onderdeel.
Wat heb je nodig om het efficiënt te laten testen?
Een specificatie. Als er documentatie is van welke API’s er zijn en wat ze doen, kan de tester gericht aan het werk en kost de test dagen minder. Is die documentatie er niet, dan moet de tester de API’s eerst ontdekken, en dan is de eerste bevinding al binnen: je weet zelf niet precies wat je aanbiedt. Dat is geen verwijt, het is de meest voorkomende situatie, en het is de reden dat een API pentest vaak begint met een inventarisatie die op zichzelf al waarde heeft.
Heb je een applicatie met koppelingen naar een app, een portaal of partners, en is daar nooit gericht naar gekeken? In een scopegesprek bepalen we of een API pentest bij jou de ontbrekende laag is.
BOEM voert pentesten uit met EHGI, het bedrijf achter de EHGN-community van 2.500+ ethische hackers, waaronder specialisten van Politie, Defensie en DIVD. Welke tester bij jouw omgeving past, bepalen we in het scopegesprek.
Veelgestelde vragen
Wat is een API pentest?
Een test van de koppelingen (API’s) waarmee applicaties met elkaar praten: de laag achter de schermen die gegevens ophaalt en wegschrijft. De tester benadert die koppelingen direct, zoals een aanvaller dat doet, in plaats van via de knoppen die een gebruiker ziet.
Test een gewone webapplicatie-pentest de API’s niet mee?
Deels. Een webtest volgt wat de browser doet en raakt daarmee de API’s die de schermen gebruiken. Maar API’s bieden vaak meer aan dan de schermen laten zien: oude versies, functies voor een mobiele app, koppelingen voor partners. Die blijven buiten beeld zonder gerichte API pentest.
Wat is de meest voorkomende API-bevinding?
Ontbrekende of onvolledige autorisatie: een API die gegevens van een andere gebruiker teruggeeft als je een nummer aanpast, of een functie die geen controle doet op wie hem aanroept. Daarnaast API’s zonder authenticatie die per ongeluk bereikbaar zijn.
Hoeveel tijd kost een API pentest?
Afhankelijk van het aantal koppelingen: een gerichte test van één applicatie met een beperkt aantal API’s kost twee tot drie dagen. Een documentatie van de API’s vooraf (een specificatie) maakt de test aanzienlijk efficiënter.
