Veel organisaties hebben wel een globaal beeld van een pentest, maar weten niet precies wat er tijdens zo’n test gebeurt. Wie eerst de basis wil begrijpen, kan lezen wat een pentest is.
Vaak ontstaat het beeld van iemand die “probeert in te breken”. Dat klopt deels, maar dat is te simpel. Een goede pentest is geen willekeurige hackpoging. Het is een gecontroleerd en gestructureerd onderzoek naar wat een aanvaller in de praktijk kan bereiken.
Daarbij kijkt een pentester niet alleen naar losse kwetsbaarheden, maar ook naar context.
Hoe werkt de applicatie?
Welke gebruikersrollen zijn er?
Welke data is gevoelig?
Aan welke systemen is de applicatie gekoppeld?
Wat zijn de gevolgen als iemand afwijkt van de standaard toegangswegen?
Juist die vragen bepalen de waarde van een pentest.
Een pentest begint met scope en voorbereiding
Een pentest begint niet met testen, maar met afbakening.
Vooraf wordt bepaald wat wel en niet onderzocht wordt. Dat lijkt misschien administratief, maar het is een belangrijk onderdeel van de test. Een onduidelijke scope leidt al snel tot verkeerde verwachtingen.
Wordt alleen de webapplicatie getest, of ook de API daarachter?
Zijn er testaccounts beschikbaar met verschillende rollen?
Valt de cloudomgeving binnen scope?
Mag er actief worden getest op productie?
Zijn betaalflows, klantdata of beheerfuncties onderdeel van het onderzoek?
Dat soort keuzes bepalen wat een pentest kan aantonen.
Een test zonder gebruikersaccounts geeft vooral inzicht in wat vanaf buiten zichtbaar is. Een test met accounts laat juist zien wat een normale gebruiker, klant, medewerker of partner kan doen binnen de applicatie.
Voor moderne applicaties is dat vaak belangrijk, omdat veel risico’s pas ontstaan nadat iemand is ingelogd.
De pentester leert eerst het systeem begrijpen
Na de voorbereiding probeert de pentester de omgeving te begrijpen.
Dat gebeurt niet alleen technisch, maar ook functioneel. Een applicatie is meer dan code, endpoints en invoervelden. Het is een verzameling aan processen, rollen, datastromen en aannames.
De pentester kijkt bijvoorbeeld hoe gebruikers inloggen, welke rollen er zijn, welke acties mogelijk zijn en welke data wordt teruggegeven. Bij API’s wordt gekeken naar requests, responses, tokens, object-ID’s en endpoints. Bij cloud- of netwerkomgevingen draait het meer om bereikbaarheid, rechten, configuraties en onderlinge verbindingen.
Deze verkenningsfase is belangrijk omdat veel kwetsbaarheden pas zichtbaar worden wanneer je begrijpt hoe het systeem echt werkt.
Een vulnerability scan kan bekende kwetsbaarheden signaleren. Maar een pentester kijkt ook naar gedrag:
Wat gebeurt er als een gebruiker een andere ID probeert?
Hoe reageert het systeem wanneer een stap wordt overgeslagen?
Wat is het effect van een request dat buiten de frontend om wordt verstuurd?
Welke gevolgen heeft het combineren van twee kleine bevindingen?
Daar begint het echte verschil.
Mogelijke kwetsbaarheden worden onderzocht
Zodra de pentester begrijpt hoe het systeem werkt, wordt gekeken waar risico’s kunnen ontstaan.
Sommige kwetsbaarheden zijn technisch. Denk aan invoervalidatie, sessiebeheer, configuratiefouten of bekende kwetsbaarheden in gebruikte software.
Maar vaak zit de meeste waarde in risico’s die niet direct uit tooling komen.
Bijvoorbeeld:
- gebruikers die toegang krijgen tot data van anderen;
- API’s die meer informatie teruggeven dan nodig;
- autorisatie die per endpoint anders werkt;
- betaalflows die te vroeg een order bevestigen;
- rollen die meer rechten hebben dan bedoeld;
- systemen die onderling meer toegang hebben dan noodzakelijk.
Dit soort kwetsbaarheden ontstaan meestal niet doordat een systeem volledig faalt. De applicatie blijft vaak gewoon werken, maar het probleem is dat ze ook gedrag toestaat dat vanuit zakelijk of securityoogpunt niet gewenst is.
Daarom vraagt een pentest om handmatige analyse.
Kwetsbaarheden worden gecontroleerd misbruikt
Een belangrijk verschil tussen signaleren en pentesten is dat een pentester probeert vast te stellen wat de impact is.
Niet alleen:
“Hier lijkt iets kwetsbaar.”
Maar:
“Wat kan iemand hiermee bereiken?”
Dat gebeurt gecontroleerd en binnen de afgesproken scope. Het doel is niet om schade aan te richten, maar om duidelijk te maken hoe ernstig een risico is.
Een autorisatieprobleem wordt bijvoorbeeld getest door te controleren of een gebruiker daadwerkelijk data van een andere gebruiker kan ophalen. Een configuratiefout wordt beoordeeld op wat daardoor bereikbaar wordt. Een kwetsbaar endpoint wordt onderzocht om te bepalen welke acties ermee mogelijk zijn en welke data toegankelijk is.
Die stap is belangrijk.
Zonder impact blijft een bevinding abstract. Met impact wordt duidelijk waarom een bevinding prioriteit zou moeten krijgen.
Een ontbrekende controle klinkt technisch.
Toegang tot klantgegevens via die ontbrekende controle is een concreet risico.
Bevindingen worden gecombineerd
In de praktijk zit de grootste impact niet altijd in één losse kwetsbaarheid.
Vaak ontstaat het echte risico door een combinatie van factoren.
Een gebruiker heeft beperkte toegang. Een API geeft iets meer data terug dan de frontend toont. Een endpoint controleert autorisatie minder strikt. Een configuratie staat net iets te ruim open.
Los van elkaar lijken deze bevindingen misschien beperkte impact te hebben.
Samen kunnen ze een aanvalspad vormen.
Een goede pentester kijkt daarom niet alleen naar individuele kwetsbaarheden, maar naar wat er mogelijk wordt wanneer bevindingen elkaar versterken. Dat is ook waarom een pentest vaak meer waarde oplevert dan een losse vulnerability scan.
Aanvallers denken niet in losse bevindingen. Ze denken in aanvalspaden.
Een pentest probeert die aanvalspaden zichtbaar te maken.
De pentester kijkt naar realistische scenario’s
Een pentest draait niet om zoveel mogelijk kwetsbaarheden vinden. Het draait om risico’s die in de praktijk relevant zijn.
Daarom kijkt een pentester naar scenario’s.
Wat mag een normale gebruiker buiten zijn rechten om doen?
Is het mogelijk dat een aanvaller vanuit één account bij andere data komt?
Geeft een API-token toegang tot meer dan bedoeld?
Leidt een configuratiefout tot toegang tot interne systemen?
Maakt een fout in de businesslogica financieel misbruik mogelijk?
Die scenario’s verschillen per omgeving.
In een webshop ligt de nadruk op betaalflows, kortingen en retouren.
Voor een API draait het om objectniveau-autorisatie en datastromen.
In een cloudomgeving staan rollen, permissies en blootstelling centraal.
Wat een netwerk betreft, gaat het om segmentatie en laterale beweging.
Bij een webapplicatie pentest ligt de nadruk vaak op accounts, rollen, sessies, autorisatie, invoervalidatie en toegang tot data.
Daarom is een goede scope zo belangrijk. De test moet aansluiten op de risico’s die voor die omgeving echt relevant zijn.
Rapportage: niet alleen wat, maar vooral waarom
Na de test worden de bevindingen vastgelegd in een rapport.
Een goed pentestrapport is meer dan een lijst met kwetsbaarheden. Het legt uit wat er is gevonden, hoe het misbruikt kan worden, wat de impact is en welke maatregel nodig is.
Dat rapport moet bruikbaar zijn voor verschillende lezers.
Ontwikkelaars en beheerders moeten begrijpen wat ze moeten oplossen. Management moet kunnen zien welke risico’s prioriteit hebben. Security- of complianceverantwoordelijken moeten kunnen aantonen welke risico’s zijn onderzocht en opgevolgd.
Een goede rapportage bevat daarom niet alleen technische details, maar ook context.
Waarom is dit een risico?
Wat kan iemand ermee?
Welke systemen of data worden geraakt?
Hoe kan het worden opgelost?
Welke bevindingen hebben de meeste prioriteit?
Dat maakt het rapport bruikbaar als verbeterdocument, niet alleen als bewijsstuk.
Hertest en opvolging
Een pentest stopt niet altijd bij het rapport.
Bij serieuze bevindingen is een hertest vaak verstandig. Daarbij controleert de pentester of de kwetsbaarheid daadwerkelijk is opgelost en of de maatregel geen nieuw probleem heeft veroorzaakt.
Dat is belangrijk, omdat fixes soms te beperkt zijn.
Een specifieke URL wordt geblokkeerd, maar hetzelfde probleem is nog aanwezig bij een vergelijkbaar endpoint. Een rol wordt aangepast, maar een andere rol houdt dezelfde te ruime rechten. Een invoerveld wordt gevalideerd, maar dezelfde data kan via de API alsnog worden aangepast.
Een hertest geeft meer zekerheid dat het probleem echt is verholpen.
Zonder opvolging blijft een pentest vooral een momentopname. Met goede opvolging wordt het onderdeel van verbetering.
Wat een pentest niet doet
Een pentest geeft geen garantie dat een systeem volledig veilig is.
Dat is belangrijk om eerlijk te benoemen.
Een pentest onderzoekt een afgesproken scope binnen een bepaalde periode. Nieuwe code, gewijzigde configuraties, extra endpoints of veranderende aanvalstechnieken kunnen later nieuwe risico’s introduceren.
De waarde van een pentest zit in het realistische perspectief. Het laat zien waar een aanvaller op dat moment kansen heeft en welke verbeteringen de meeste impact hebben.
Daarom moet een pentest niet worden gezien als eindpunt, maar als input voor betere securitybeslissingen.
Waarom een pentest meer is dan een vulnerability scan
Een vulnerability scan kan nuttig zijn om bekende kwetsbaarheden en zichtbare configuratieproblemen te signaleren.
Maar tijdens een pentest gebeurt iets anders.
Een pentester probeert te begrijpen hoe het systeem werkt, hoe kwetsbaarheden kunnen worden misbruikt en welke impact dat heeft. Daarbij spelen context, rollen, datastromen, businesslogica en samenhang tussen systemen een grote rol.
Een vulnerability scan kan bijvoorbeeld aangeven dat een systeem een bekende kwetsbaarheid bevat. Een pentest onderzoekt wat daarmee mogelijk is binnen de specifieke omgeving.
Een vulnerability scan geeft overzicht.
Een pentest geeft inzicht in misbruik en impact.
Daarom vullen ze elkaar aan, maar vervangen ze elkaar niet. Lees ook het verschil tussen een vulnerability scan en een pentest.
Hoe dit invloed heeft op kosten en planning
Wat er tijdens een pentest gebeurt, heeft direct invloed op de kosten en planning.
Een beperkte test op een kleine applicatie kost minder tijd dan een diepgaande analyse van een platform met meerdere rollen, API-koppelingen, businesslogica en gevoelige data.
De grootste tijd zit vaak niet in het draaien van tools, maar in begrijpen, testen, combineren en onderbouwen.
Daarom kunnen pentest kosten sterk verschillen. Een oppervlakkige controle op bekende kwetsbaarheden vraagt minder tijd dan een test waarbij realistische aanvalsscenario’s worden onderzocht.
Ook frequentie speelt mee. Een pentest is een momentopname. Systemen die regelmatig veranderen, vragen soms om vaker of gerichter testen dan stabiele omgevingen. Lees ook hoe vaak een pentest nodig is.
Van test naar risicobeeld
Tijdens een pentest wordt een systeem niet alleen gecontroleerd, maar actief onderzocht vanuit het perspectief van een aanvaller.
Dat maakt het verschil.
Een goede pentest laat niet alleen zien waar kwetsbaarheden zitten, maar vooral wat die kwetsbaarheden betekenen. Welke data kan in gevaar komen? Kan een aanvaller acties uitvoeren? Welke systemen kunnen worden bereikt? En welke bevindingen versterken elkaar?
Die context helpt organisaties om betere keuzes te maken.
Niet alles hoeft tegelijk opgelost te worden. Maar je wilt wel weten welke risico’s de meeste impact hebben.
Wil je een eerste beeld krijgen van zichtbare risico’s in jouw applicatie? Dan is een gratis security check een laagdrempelige eerste stap. Blijkt daaruit dat er meer diepgang nodig is, dan kan een pentest helpen om de impact verder te onderzoeken.