Wat is een black box pentest?

Een black box pentest is een penetratietest waarbij de tester geen informatie of inloggegevens krijgt buiten een doelnaam, domein of IP-reeks, en al het andere zelf moet ontdekken zoals een anonieme aanvaller dat zou doen. Het is de meest realistische simulatie van een opportunistische buitenstaander en de minst grondige voor alles achter authenticatie, omdat een tester met een vast tijdbudget niet bereikt wat een echte aanvaller met maanden de tijd zou bereiken.

Wat is een grey box pentest?

Een grey box pentest geeft de tester gedeeltelijke voorkennis: werkende inloggegevens per gebruikersrol, een architectuuroverzicht en documentatie, maar geen broncode. Hij simuleert een geauthenticeerde gebruiker, een insider of een aanvaller die al één account heeft overgenomen, en vindt voor de meeste applicaties en netwerken de meeste kwetsbaarheden per testdag. Het is het standaard kennisniveau voor compliancegedreven testen.

Wat is een white box pentest, en is crystal box hetzelfde?

Een white box pentest geeft de tester volledige voorkennis: inloggegevens, documentatie, broncode, configuratie en infrastructure-as-code, en combineert codereview met dynamisch testen. Crystal box, glass box en clear box zijn synoniemen voor white box. Deze aanpak vindt de diepste fouten, zoals zwakke cryptografie, hardgecodeerde geheimen en injectie in zelden gebruikte codepaden, en is de juiste keuze voor kritieke modules en codereviewverplichtingen.

Welke aanpak is het meest realistisch?

Black box is de meest realistische simulatie van een anonieme buitenstaander aan de perimeter, en grey box is de meest realistische simulatie van de aanvaller achter de meeste inbreuken: iemand met een geldig account, verkregen via phishing of gelekte wachtwoorden. Realisme is niet hetzelfde als grondigheid. Een echte aanvaller heeft onbeperkt de tijd en een tester niet, dus de tester informatie geven compenseert het tijdbudget.

Welke aanpak vindt de meeste kwetsbaarheden?

Grey box vindt voor het merendeel van de webapplicaties, API's, mobiele apps en interne netwerken de meeste kwetsbaarheden per testdag, omdat het budget naar testen gaat in plaats van naar discovery en omdat autorisatie- en bedrijfslogicafouten alleen met accounts bereikbaar zijn. White box vindt in absolute zin het meest wanneer de scope broncode omvat, tegen de prijs van leestijd.

Verandert het kennisniveau de duur of de kosten van een pentest?

Het verandert vooral hoe de dagen worden besteed, niet zozeer hoeveel dagen er zijn. Black box bespaart zelden dagen; het besteedt ze aan verkenning en levert minder bevindingen op. White box voegt voorbereiding toe aan uw kant en leestijd aan de kant van de tester. HackersHub offreert elke test op een schriftelijke scope die het kennisniveau, het aantal dagen en het aan te leveren materiaal benoemt.

Welk kennisniveau accepteren auditors en toezichthouders?

Alle drie, mits scope, methodiek en kwalificaties van de testers gedocumenteerd zijn. ISO 27001, SOC 2 en NIS2 schrijven geen kennisniveau voor, maar auditors verwachten dat applicatie- en interne tests geauthenticeerd zijn, en dat betekent grey box. PCI DSS Requirement 11.4 accepteert elke in de sector geaccepteerde methodiek, terwijl Requirement 6.2.3 en DORA artikel 25 codereview toevoegen, wat white box toegang tot de betreffende code impliceert.

Kunnen we black box, grey box en white box in één opdracht combineren?

Ja, en dat is vaak de beste scoping. Een gefaseerde test begint met een of twee ongeauthenticeerde dagen, gaat verder met inloggegevens per rol en voegt gerichte codetoegang toe voor de modules waar een oorzaak bevestigd moet worden. Het rapport vermeldt bij elke bevinding op welk kennisniveau zij is gevonden.

1 november 2026 · 11 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)

Black box, grey box of white box pentest: wat elke aanpak vindt, wat zij mist en welke u kiest

Het kennisniveau dat u een pentester meegeeft, is de scopingkeuze die het meest bepaalt wat een penetratietest per dag oplevert. Deze gids definieert de drie niveaus, laat dezelfde webapplicatie drie keer testen en legt uit waarom grey box onze standaard is, en wanneer niet.

Plan een penetratietest

Drie kennisniveaus, één vraag: wat weet de tester op dag één?

Black box, grey box en white box beschrijven hoeveel informatie en toegang de organisatie de pentester geeft voordat het testen begint. Verder verandert er niets: het doelwit, de methodiek (PTES, OWASP WSTG, NIST SP 800-115) en de rapportage zijn gelijk. Wat verandert, is waar de testdagen naartoe gaan. Bij een black box pentest begint de tester met een bedrijfsnaam, een domein of een IP-reeks en moet hij al het andere zelf ontdekken, precies zoals een anonieme aanvaller dat zou doen. Bij een grey box pentest krijgt de tester werkende inloggegevens per gebruikersrol, een architectuuroverzicht en de documentatie die er is, en besteedt hij de dagen aan testen in plaats van aan verkenning. Bij een white box pentest krijgt de tester daarbovenop broncode, infrastructuurconfiguratie en ontwerpdocumenten, en kan hij lezen hoe een beveiligingsmaatregel is gebouwd in plaats van dat van buitenaf af te leiden.

De termen komen uit het softwaretesten, waar een black box een systeem is dat u alleen via invoer en uitvoer kunt waarnemen en een white box een systeem waarvan u de binnenkant kunt inspecteren. White box heet ook wel crystal box, glass box of clear box; dat zijn synoniemen, al gebruiken sommige aanbieders crystal box om een volledig samenwerkende test aan te duiden waarbij ontwikkelaars naast de tester zitten. Grey box wordt ook geschreven als gray box of greybox. De Web Security Testing Guide van OWASP merkt op dat een zuivere black-box-aanpak beperkt wat een webapplicatietest kan dekken, en adviseert testers accounts en documentatie te geven; dat advies is de reden dat grey box de standaard is geworden voor applicatietesten.

Het kennisniveau staat los van de twee andere scopingassen: positie (extern, intern, assumed breach) en doelwit (netwerk, webapplicatie, API, mobiel, cloud). Een externe black box perimetertest en een interne grey box Active Directory-test komen beide vaak voor, net als een white box review van een betaalmodule binnen een verder grey box applicatietest. Voor de volledige indeling verwijzen wij naar onze gids over alle soorten pentesten; dit artikel blijft op de kennisas.

De drie niveaus in één oogopslag

Wat de tester krijgt, wie de test simuleert en wat hij wel en niet kan bereiken.

Black box: geen voorkennis

De tester krijgt een doelnaam, domein of IP-reeks en verder niets. Verkenning, enumeratie en discovery maken deel uit van de test. Simuleert een opportunistische externe aanvaller met een vast tijdbudget. Vindt wat zonder inloggegevens bereikbaar en uitbuitbaar is; ziet niets achter de login, tenzij hij inbreekt.

Grey box: gedeeltelijke voorkennis

De tester krijgt inloggegevens per rol, een architectuuroverzicht, API-documentatie en een contactpersoon die vragen beantwoordt. Simuleert een klant, partner, medewerker of een aanvaller die al één account heeft gephisht. Vindt autorisatiefouten, misbruik van bedrijfslogica en privilege-escalatie waar black box nooit komt.

White box: volledige voorkennis

De tester krijgt alles van grey box plus broncode, infrastructure-as-code, configuratie en ontwerpdocumenten, en combineert dynamisch testen met codereview. Vindt de diepste categorieën fouten: zwakke cryptografie, hardgecodeerde geheimen, injectie in zelden gebruikte paden, logicafouten die alleen in code zichtbaar zijn. Ook crystal box, glass box of clear box genoemd.

Black box, grey box en white box naast elkaar

De criteria die inkopers tijdens de scoping stellen, per kennisniveau beantwoord.

Criterium	Black box	Grey box	White box
Verstrekte informatie	Doelnaam, domein of IP-reeks	Inloggegevens per rol, architectuuroverzicht, documentatie, een contactpersoon	Grey box plus broncode, configuratie, infrastructure-as-code, ontwerpdocumenten
Gesimuleerde aanvaller	Anonieme buitenstaander met een tijdslimiet	Geauthenticeerde gebruiker, insider, of aanvaller na een geslaagde phishing	Insider met codetoegang, of een langdurige tegenstander die het systeem heeft bestudeerd
Realisme	Hoogst voor de externe perimeter; laagst voor alles achter de login	Hoog voor de dreigingen achter de meeste inbreuken: accountmisbruik, autorisatiefouten	Laagst als aanvalssimulatie, hoogst als assurance-oefening
Dekking per testdag	Laagst: de eerste dagen gaan naar discovery	Hoogst voor de meeste applicaties en netwerken	Hoog, maar voorbereiding en leestijd concurreren met testtijd
Gemiste bevindingen (false negatives)	Veel: alles achter authenticatie en alles wat discovery niet aan het licht bracht	Weinig op applicatieniveau; fouten die alleen in code zichtbaar zijn, blijven liggen	Minst; beperkt tot configuratie en gedrag dat alleen in productie bestaat
Voorbereiding aan uw kant	Minimaal: een doellijst en een machtigingsbrief	Testaccounts per rol, testdata, allowlisting, een aanspreekpunt	Grey box plus leestoegang tot de repository, build-instructies, een NDA voor broncode
Compliance-fit	Geaccepteerd als perimeterbewijs (ISO 27001 A.8.8, PCI DSS 11.4.3 extern)	Wat de meeste auditors verwachten voor applicatie- en interne tests (ISO 27001 A.8.29, PCI DSS 11.4.2, DORA art. 25)	Vereist waar codereview is voorgeschreven (PCI DSS 6.2.3, DORA art. 25 broncodebeoordeling, hogere OWASP ASVS-niveaus)

Dezelfde webapplicatie, drie keer getest

Een schadeportaal van een verzekeraar: klanten dienen claims in, tussenpersonen beheren de claims van hun klanten, beheerders keuren uitbetalingen goed. Een REST-API bedient de webfrontend en een mobiele app, en een nachtelijke taak exporteert goedgekeurde claims naar de financiële administratie. Vijf testdagen per aanpak. Dit zou elke aanpak realistisch vinden en missen.

Black box: de perimeter en de inlogpagina

Dag één en twee gaan naar discovery: subdomeinen opsommen, de technologiestack herkennen, elke pagina en elk API-endpoint zonder authenticatie in kaart brengen. Dag drie tot vijf testen wat zonder account bereikbaar is: de inlog- en wachtwoordherstelflow, rate limiting, sessiebeheer, TLS-configuratie, blootgestelde beheerpaden, te uitgebreide foutmeldingen en verouderde JavaScript-bibliotheken. Waarschijnlijke bevindingen: gebruikersenumeratie via het antwoord van het wachtwoordherstel, ontbrekende rate limiting op de login, een stagingserver die vanaf internet bereikbaar is gebleven, twee bibliotheken met gepubliceerde CVE's. Volledig gemist: elke autorisatiefout tussen klanten en tussenpersonen, de privilege-escalatie naar beheerder, de mass-assignment-fout op het profielendpoint, de server-side request forgery in de webhookfunctie en de stored cross-site scripting in claimnotities, omdat geen daarvan zonder geldig account bereikbaar is.

Grey box: elke rol, elke workflow

Met één account per rol, het architectuurdiagram en de API-documentatie gaat dag één naar het in kaart brengen van de applicatie per rol en het lezen van hoe de API verzoeken autoriseert. Dag twee tot vijf testen elke workflow als elke rol, wisselen identifiers tussen accounts, manipuleren verzoekparameters en ketenen wat gevonden wordt. Waarschijnlijke bevindingen: klanten kunnen claims van andere klanten lezen door een oplopend nummer aan te passen (broken object level authorisation), tussenpersonen kunnen via een ongevalideerde filterparameter klanten van andere tussenpersonen opvragen, een klant kan zijn eigen account via mass assignment op geverifieerd zetten, het webhook-URL-veld accepteert interne adressen en bereikt de metadataservice van de cloud, en claimnotities worden zonder escaping getoond in de beheerdersweergave. Gemist: een voorspelbare seed in de generator van wachtwoordhersteltokens, string-concatenatie in een zelden gebruikte rapportagequery, een hardgecodeerde API-sleutel voor de aanbieder van digitale ondertekening, en een race condition in de tweestaps goedkeuring van uitbetalingen.

White box: de code toont wat de runtime verbergt

Met leestoegang tot de repositories en de infrastructure-as-code leest de tester eerst de authenticatie-, autorisatie- en betaalmodules en gebruikt hij de draaiende applicatie om te bevestigen wat de code suggereert. Waarschijnlijke bevindingen: alles wat grey box vond, plus het voorspelbare hersteltoken (binnen minuten zichtbaar in de tokengenerator), de SQL-concatenatie in de rapportagemodule, de hardgecodeerde ondertekeningssleutel, een volledige analyse van alle afhankelijkheden, de ontbrekende autorisatiecontrole op de exportroute achter een feature flag, en een te ruime IAM-rol in de deploymenttemplates. Gemist of zwakker: gedrag dat alleen in productie bestaat, zoals de regel in de web application firewall die een payload daadwerkelijk blokkeert die de code zou accepteren, een loadbalancer-header die de IP-allowlist omzeilt, en, als simulatie, elk gevoel voor hoe lang een echte aanvaller nodig zou hebben om dit alles van buitenaf te vinden. White box kost ook leestijd: van vijf dagen gaan er ruwweg twee naar code voordat de eerste dynamische test begint.

Wanneer kiest u black box, grey box of white box?

Kies op de vraag die beantwoord moet worden, niet op de aanpak die het strengst klinkt.

Kies black box wanneer de blik van de buitenstaander de vraag is

Een eerste blik op de perimeter van een overnamekandidaat wanneer u nog geen inloggegevens kunt vragen. Bevestigen dat een internet-facing systeem zonder authenticatie niets blootgeeft. Een gefaseerde eerste stap van een of twee dagen voordat de inloggegevens worden overgedragen. Black box is geen keuze voor compliancebewijs over applicatiebeveiliging, en het is geen manier om dagen te besparen: een black box pentest van een systeem met authenticatie duurt meestal even lang als een grey box pentest en vindt minder.

Kies grey box wanneer u de meeste bevindingen per dag wilt

Jaarlijkse compliancetests voor ISO 27001, NIS2, DORA artikel 25 en PCI DSS Requirement 11.4. Elke applicatie met gebruikersrollen of multi-tenancy. Interne netwerktests als assumed breach vanaf een standaard gebruikersaccount. Mobiele apps en API's, die vrijwel volledig uit geauthenticeerd oppervlak bestaan. Een eerste test van elk systeem dat klantdata bevat. Dit is de standaard die wij scopen, om de redenen die hieronder staan.

Kies white box wanneer de fouten die u vreest in de code zitten

Betaal-, cryptografie- en authenticatiemodules. Software die u verkoopt aan klanten die haar zelf zullen testen. Codereviewverplichtingen onder PCI DSS Requirement 6.2.3 of DORA artikel 25. Testen vóór de release van een nieuw platform, wanneer herstellen het minst verstorend is. Systemen met hoge assurance-eisen zoals medische apparatuur, industriële besturingen en identity providers. Combineer white box met dynamisch testen: codereview alleen mist deployment- en runtimeproblemen.

Tijd, diepte en budget: de afweging in woorden

Elke penetratietest is een vast aantal consultantdagen. Het kennisniveau bepaalt hoe die dagen worden besteed. Bij black box betaalt het eerste deel van het budget voor verkenning die u gratis had kunnen aanleveren. Bij grey box verschuift dat budget naar testen, en daarom vindt grey box meer per dag en clusteren de bevindingen in de categorieën die echte inbreuken veroorzaken: broken access control, dat sinds 2021 bovenaan de OWASP Top 10 staat, en misbruik van bedrijfslogica. Bij white box verschuift een deel van het budget naar het lezen van code, wat de diepste fouten vindt maar de eerste dynamische bevinding uitstelt en testers vraagt die thuis zijn in uw programmeertaal en framework.

Realisme en grondigheid zijn verschillende doelen. Een echte aanvaller is niet gebonden aan vijf dagen; een tester wel. De tester de informatie geven die een aanvaller uiteindelijk zou bemachtigen, is de manier om de uiteindelijke positie van die aanvaller te simuleren binnen de tijd waarvoor u betaalt. White box vraagt meer voorbereiding van u (repositorytoegang, NDA's, build-instructies) en meer leestijd van ons, en levert het meest complete beeld op; of dat de moeite waard is, hangt af van hoe kritiek de code is en of er een codereviewverplichting geldt.

Een gefaseerde aanpak haalt het grootste deel van het voordeel uit elk niveau: een of twee dagen black box om de ongeauthenticeerde blik en de discoveryresultaten vast te leggen, daarna inloggegevens voor de resterende dagen, met gerichte codetoegang voor de modules waar de grey-box-fase iets vond dat een oorzaak nodig heeft. Het rapport vermeldt dan per bevinding op welk kennisniveau zij is gevonden. Zo weet u welke bevindingen een anonieme aanvaller vandaag kan bereiken en welke een account of insiderpositie vereisen.

Wat u klaar moet hebben voor een grey box of white box test

De voorbereiding die overgedragen kennis omzet in testdagen.

Eén testaccount per gebruikersrol, inclusief de rol met de hoogste rechten, en minimaal twee accounts per rol zodat horizontale autorisatie getest kan worden
Representatieve testdata, of een stagingomgeving die de productieconfiguratie spiegelt; wordt productie getest, dan afgesproken uitsluitingen en een contactpersoon voor rollback
Een architectuuroverzicht: componenten, vertrouwensgrenzen, integraties met derden, authenticatieprovider
API-documentatie (OpenAPI, GraphQL-schema of een verzoekencollectie) en de mobiele builds als die in scope zijn
Allowlisting van de bronadressen van de tester in de web application firewall en de rate limiter, of een expliciet besluit om met die maatregelen actief te testen
Een technisch aanspreekpunt bij naam dat binnen de dag vragen beantwoordt en accounts kan ontgrendelen
Voor white box: leestoegang tot de repository, build- en deploymentinstructies, infrastructure-as-code en een NDA die broncode dekt
Een machtigingsbrief die de doelwitten, het testvenster, het kennisniveau en het escalatiepad voor kritieke bevindingen benoemt

Hoe HackersHub het kennisniveau scopet: grey box als standaard

Wij scopen grey box als standaard voor applicatie-, API-, mobiele, cloud- en interne netwerktests, omdat het de meeste bevindingen per consultantdag oplevert, de aanvallerspositie achter de meeste inbreuken spiegelt (een geldig account, verkregen via phishing of credential stuffing) en het bewijs per rol levert waar auditors naar vragen onder ISO 27001 A.8.29, PCI DSS Requirement 11.4 en DORA artikel 25. Elke grey box opdracht begint met een korte ongeauthenticeerde fase, zodat het rapport ook vastlegt wat een anonieme buitenstaander ziet.

Wij adviseren black box als zelfstandig niveau voor externe perimetertests, voor verkenning vóór een overname wanneer inloggegevens nog niet gevraagd kunnen worden, en wanneer een opdrachtgever specifiek de blik van de buitenstaander wil meten. Wij adviseren white box, als gecombineerde codereview en dynamische test, voor betaal-, cryptografie- en authenticatiecode, voor software vóór de eerste release en overal waar een codereviewverplichting geldt. In elk geval benoemt de scopeverklaring het kennisniveau, de accounts en het materiaal dat wordt aangeleverd, en de gevolgde methodiek (PTES, OWASP WSTG en MASTG, NIST SP 800-115).

Rapporten bevatten een managementsamenvatting, CVSS-gescoorde bevindingen met bewijs, een aanvalsnarratief dat laat zien hoe bevindingen zich ketenen, en geprioriteerd herstel. Een verificatiehertest van bevindingen vanaf medium binnen 90 dagen is inbegrepen. Elke tester heeft minimaal OSCP; OSWE-gecertificeerde testers leiden white box opdrachten, omdat code lezen op kwetsbaarheden een andere vaardigheid is dan een draaiend systeem uitbuiten. Lead tester Michael van Mameren beoordeelt elke scope. HackersHub levert al meer dan tien jaar offensive security vanuit Amsterdam en wordt beoordeeld met 4,9/5 over 127 reviews.

Veelgestelde vragen

Gerelateerde gidsen en diensten

Weet u niet zeker welk kennisniveau bij uw systeem past?

Een scopinggesprek van 20 minuten bepaalt black, grey of white box per doelwit, benoemt de accounts en het materiaal dat wij nodig hebben, en levert een schriftelijke scope met dagtelling en lead tester bij naam. Praat met een expert.

Plan een penetratietest Praat met een expert