Black box, grey box en white box pentest: wat is het verschil?
Het verschil tussen black box, grey box en white box zit in de hoeveelheid voorkennis die de pentester vooraf krijgt:
- Bij een black box pentest start de tester zonder informatie, net als een aanvaller van buitenaf.
- Bij een grey box pentest werk je met beperkte voorkennis, zoals inloggegevens.
- Bij een white box pentest deelt je organisatie alles, tot en met broncode en architectuur.
Elke vorm beantwoordt een andere vraag over je beveiliging. De juiste keuze hangt af van wat je wilt weten, niet van welke vorm het grondigst klinkt.
Black box is meest gangbaar
Veel organisaties die voor het eerst een pentest aanvragen kiezen automatisch voor black box, omdat dat het meest op een echte aanval lijkt. Dat klinkt logisch. Toch ontdek je daarmee lang niet altijd de meeste risico’s.
Hieronder lees je precies wat de drie vormen inhouden, waar de meeste uitleg de plank misslaat, en hoe je de vorm kiest die past bij jouw applicatie, netwerk of API.
Snelle vergelijking: black box, grey box en white box
| Aspect | Black box | Grey box | White box |
|---|---|---|---|
| Voorkennis | Geen informatie vooraf | Beperkte informatie, zoals accounts | Volledige informatie, ook broncode |
| Perspectief | Externe aanvaller zonder toegang | Aanvaller die al een account bemachtigde | Interne review met alle kaarten open |
| Verkenningsfase | Lang, tester brengt zelf alles in kaart | Kort, blinde verkenning valt weg | Minimaal, alle documentatie ligt klaar |
| Doorlooptijd per scope | Langer door verkenning | Meer bevindingen per dag | Diep, tijdrovend door hoeveelheid data |
| Beantwoordt de vraag | Wat bereikt een buitenstaander? | Wat kan een gebruiker die binnen is? | Waar zit de zwakte in de bouw zelf? |
| Sterkste bij | Externe aanvalsoppervlakte, detectie | Webapplicaties, API’s, brede dekking | Code-review, maatwerk, kritische systemen |
Waar het echte verschil zit: kennis versus toegang
Hier gaat de meeste uitleg de mist in. Veel bronnen zetten de drie vormen op één schuifbalk van weinig naar veel rechten. Dat klopt niet. Kennis en toegang zijn twee losse assen. De kleur van de box beschrijft de kennis van de tester, niet zijn rechten of toegang.
Een voorbeeld maakt dat helder. Een black box tester kan volledige toegang hebben tot elke functie van je applicatie, terwijl hij geen idee heeft hoe die functies onder de motorkap werken. Andersom kan een white box tester de complete broncode lezen zonder ooit een draaiend systeem aan te raken. Toegang tot code betekent dus geen toegang tot productie. Wie deze twee assen door elkaar haalt, kiest vaak de verkeerde vorm.
De kaders die de vakwereld hanteert, zoals OWASP WSTG, PTES en NIST SP 800-115, definiëren black box als testen met weinig tot geen voorkennis. In de praktijk valt dat vaak samen met een externe, niet-ingelogde positie. Altijd is dat niet zo. Je kunt ook black box testen op een intern netwerk: de tester heeft dan netwerktoegang, zonder documentatie over hoe de systemen werken.
Black box pentest uitgelegd
Bij een black box pentest ontvangt de tester vooraf geen informatie over de omgeving. Geen accounts. Geen technische documentatie. Geen architectuurdiagrammen. Je geeft bijvoorbeeld een domeinnaam of een applicatie, en de tester ontdekt vervolgens zelf hoe alles in elkaar zit.
Dit spiegelt de aanpak van een aanvaller die je inlogpagina vindt, je databaseschema niet kent, en toch met elke zichtbare functie aan de slag gaat. De tester start met verkenning: openbare informatie verzamelen, endpoints in kaart brengen, en zoeken naar de eerste ingang. Vanaf daar zoekt hij naar zwakke plekken zoals misconfiguraties, injecties en fouten in de bedrijfslogica.
Wat een black box pentest níet is
Let hier op, want dit scheelt je geld. Een black box pentest is geen scan vanaf het internet zonder inloggegevens. Dat is een vulnerability scan, een geautomatiseerde controle die bekende zwakke plekken oplijst.
Een echte black box pentest test elke bereikbare functie handmatig: authenticatie, autorisatie, invoervalidatie en de logica achter je processen. Krijg je een verdacht lage prijs voor een “black box pentest”, dan koop je waarschijnlijk een scan die als pentest wordt verkocht. Het verschil zie je terug in de diepgang van het rapport.
Wanneer past black box?
Kies black box wanneer realisme het doel is. Wil je weten of een externe aanvaller binnenkomt en of je dat opmerkt, dan is het achterhouden van kennis juist de test. Deze vorm past bij het valideren van een publiek bereikbare aanvalsoppervlakte en bij het toetsen van je detectie en respons.
Het nadeel: een deel van de tijd gaat op aan verkenning. Die verkenning hoort bij een realistische aanval, tegelijk blijft er minder tijd over voor diepgaand onderzoek achter een login. Juist daar zitten tegenwoordig vaak de interessante risico’s.
Grey box pentest uitgelegd
Bij een grey box pentest krijgt de tester beperkte voorkennis vooraf. Vaak gaat het om een set testaccounts voor verschillende rollen, bijvoorbeeld een gewone gebruiker, een gebruiker met extra rechten en een beheerder. Soms komt daar een architectuuroverzicht of een deel van de broncode bij. De tester begint dus niet volledig blind, en valt de omgeving nog steeds aan zoals een aanvaller dat zou doen.
Deze vorm is in de praktijk de meest gevraagde. De reden is simpel: veel aanvallen beginnen niet volledig blind. Aanvallers gebruiken gelekte accounts, gestolen sessies of openbare documentatie. Een grey box test bootst precies die aanvaller na, iemand die zijn huiswerk heeft gedaan. Doordat de blinde verkenning wegvalt, gaat meer tijd naar het echte onderzoek. Dat levert meer bevindingen per dag.
Waarom rollen en accounts het verschil maken
Met meerdere rol-accounts test je autorisatie pas echt. De kernvraag luidt: kan gebruiker A bij de gegevens van gebruiker B? Denk aan een klantportaal waar iemand het ordernummer in de URL aanpast en ineens de factuur van een ander ziet. Dit soort fouten, bekend als kapotte objectautorisatie, vind je alleen wanneer je met verschillende accounts naast elkaar test. Met één account blijft deze hele categorie risico’s onzichtbaar. Voor een webshop, klantportaal of API met gevoelige data is dat het belangrijkste onderdeel van de test.
White box pentest uitgelegd
Bij een white box pentest deelt je organisatie uitgebreide informatie: documentatie, architectuurdiagrammen en broncode. Deze vorm heet ook wel crystal box. De tester weet vooraf hoe het systeem is opgebouwd en kan gericht op zoek naar zwakke plekken in de bouw zelf.
White box is de enige vorm waarbij de tester statische code-analyse doet: de broncode doorlezen op zoek naar fouten in invoervalidatie, cryptografie en autorisatiemodellen.
Daar zitten risico’s die je van buitenaf binnen een normale testperiode zelden ontdekt. De uitdaging is de hoeveelheid data. Door alle documentatie en code moet de tester de zwakke punten zien te vinden, wat deze vorm de meest tijdrovende maakt.
Let op een veelgehoord misverstand. Meer diepgang betekent niet automatisch een realistischer beeld. Een white box test simuleert het perspectief van een externe aanvaller juist minder sterk, omdat de tester werkt met kennis die een aanvaller nooit heeft. White box past daarom bij code-review vóór een release, bij maatwerkapplicaties en bij kleine maar kritische systemen.
Eén kwetsbaarheid, drie invalshoeken
Neem een order-API met een autorisatiefout, waardoor account A de bestellingen van account B kan opvragen. Dezelfde fout laat zich op drie manieren vinden, met drie verschillende uitkomsten.
- Black box: de tester ontdekt de fout door ID’s te fuzzen en merkt dat één account de orders van een ander inziet. Hij weet dát het kan, zonder te weten waarom.
- White box: de tester leest de autorisatiecheck in de code en vindt de fout sneller. Tegelijk mist hij mogelijk een configuratiefout die pas op de live-omgeving zichtbaar wordt.
- Grey box: met twee rol-accounts én het codepad bevestigt de tester de fout, brengt elk ander endpoint met dezelfde zwakke check in kaart, en geeft de exacte regel terug om te herstellen.
Dezelfde bug, drie verschillende beelden van de reikwijdte en drie verschillende doorlooptijden. Zo zie je waarom de vorm die je kiest het resultaat stuurt.
Welke aanpak past bij welke situatie?
De vorm volgt uit je doel en uit het type systeem dat je test. Deze tabel helpt je richting te bepalen.
| Situatie | Passende aanpak |
|---|---|
| Publieke website, externe aanvalsoppervlakte toetsen | Black box |
| Webapplicatie of API met login en gevoelige data | Grey box met meerdere rollen |
| Klantportaal of webshop, autorisatie tussen gebruikers | Grey box |
| Maatwerkapplicatie vóór livegang, code-review | White box of grey box |
| Intern netwerk, wat kan iemand die al binnen is | Grey box of black box intern |
| Jaarlijkse compliance-toets, brede dekking gewenst | Grey box |
Twijfel je nog? Lees dan eerst wat een pentest is en bekijk het verschil tussen pentest en vulnerability scan. Zo weet je zeker dat je de juiste dienst vergelijkt.
Aanpakken naast elkaar inzetten
In de praktijk voegen we vormen vaak samen. Een black box verkenning van buitenaf, gevolgd door een grey box applicatietest achter de login. Een andere route is een white box code-review naast een grey box test op de draaiende omgeving. Deze hybride aanpak geeft je zowel het aanvallersperspectief als de diepgang van interne kennis. Wat past, hangt af van je scope, je budget en je doel.
Een variant die je vaker tegenkomt is de assumed breach. Daarbij ga je ervan uit dat een aanvaller al één voet binnen heeft, bijvoorbeeld via een gestolen account. De test richt zich dan op de vraag hoe ver iemand vanaf dat punt komt. Dat is realistischer dan het scenario waarin een aanvaller helemaal niets weet.
Compliance: wat auditors verwachten
Steeds meer Nederlandse organisaties laten testen vanwege wet- en regelgeving. De kleur van de box staat zelden letterlijk in een norm. Wat auditors verwachten, is bewijs dat je je risico’s daadwerkelijk beheerst. Een paar kaders op een rij.
- NIS2 en de Cyberbeveiligingswet. NIS2 noemt het woord pentest niet expliciet. Artikel 21 verlangt wel dat je de doeltreffendheid van je beveiligingsmaatregelen periodiek beoordeelt. Een pentest is daarvoor een van de meest gebruikte vormen van technische toetsing. De Nederlandse invulling loopt via de Cyberbeveiligingswet, met handhaving voorzien in 2026.
- DORA. Voor financiële instellingen binnen scope vraagt artikel 26 om Threat-Led Penetration Testing, een aanvalssimulatie op basis van dreigingsinformatie, sinds 17 januari 2025.
- PCI DSS. Requirement 11.4 vraagt om zowel externe als interne penetratietesten.
- ISO 27001. De norm behandelt testen als een maatregel binnen risicobeheer, zonder een vaste box-kleur voor te schrijven.
Voor de meeste audits geldt: auditors verwachten dat je zowel externe aanvalsscenario’s toetst als de risico’s van binnenuit. Een test die alleen publieke poorten scant, dekt die verwachting zelden. Een rapport dat als onderbouwing dient in een audit heeft daarom meer waarde dan een losse lijst met kwetsbaarheden.
Waar let je op bij het kiezen van een pentestpartij?
De vorm is één keuze. De partij die de test uitvoert is de tweede, en zeker zo bepalend. Let op deze punten:
- CCV Pentest Keurmerk. Dit Nederlandse keurmerk borgt dat een test volgens vastgelegde normen verloopt. Voor publieke en gereguleerde organisaties is het vaak de standaard bij aanbestedingen.
- Certificeringen van de testers. Denk aan OSCP, OSWE en OSEP. Vraag welke gecertificeerde tester daadwerkelijk aan jouw opdracht werkt.
- Handmatig werk. Een sterke pentest bestaat voor het grootste deel uit handmatig onderzoek, aangevuld met tooling. Niet andersom.
- Herstel en hertest. Vraag of een hertest is inbegrepen. Zonder bewijs van herstel is een test voor veel audits onvoldoende.
- Heldere scope en prijs. Een reële prijs hoort bij de diepgang die je vraagt. De kosten van een pentest volgen uit de omvang: het aantal applicaties, netwerksegmenten en endpoints.
Wil je sparren over de vorm die past bij jouw situatie? Vraag een vrijblijvend gesprek aan. We bepalen samen welke aanpak de vraag beantwoordt die voor jou telt.
Veelgestelde vragen
Wat is het verschil tussen black box, grey box en white box pentesten?
Het verschil zit in de voorkennis van de tester. Black box start zonder informatie, grey box met beperkte informatie zoals accounts, en white box met volledige informatie tot en met broncode. Elke vorm beantwoordt een andere vraag over je beveiliging.
Welke pentest is het meest realistisch?
Niet per definitie black box. Echte aanvallers verzamelen vooraf kennis via verkenning, gelekte accounts of social engineering. Een grey box test bootst zo’n aanvaller die zijn huiswerk deed vaak realistischer na dan een scenario waarin de tester helemaal niets weet.
Betekent white box dat de tester beheerdersrechten heeft?
Nee. White box gaat over kennis, zoals broncode en documentatie, en niet over toegang. Een white box test kan bestaan uit een code-review zonder dat de tester ooit een draaiend systeem aanraakt.
Welke pentest is het duurst?
Black box loopt per applicatie vaak langer door de verkenningsfase, wat de doorlooptijd verhoogt. Grey box levert doorgaans de meeste bevindingen per dag, doordat de blinde verkenning wegvalt.
Welke vorm heb ik nodig voor NIS2 of ISO 27001?
Geen van beide schrijft een vaste box-kleur voor. Auditors verwachten dat je zowel externe als interne risico’s toetst en dat je herstel aantoont. Voor de meeste organisaties dekt een grey box test met externe verkenning die verwachting.
Kun je black box testen op een intern netwerk?
Ja. Bij black box intern heeft de tester netwerktoegang, zonder documentatie over hoe de interne systemen werken. Hij test alles wat bereikbaar is, zonder te weten hoe het onder de motorkap in elkaar zit.
