Black, Grey and White Box Testing

Three terms appear in almost every proposal, and they describe one thing: how much information the tester is given before they start.

They do not describe how much access the tester gets. That is a separate decision — whether they hold an account, and how many roles — and confusing the two is the most common misunderstanding in scoping conversations. You can perfectly well run a black box test with a user account: you were told nothing about how the system works, but you were given credentials.

The three

Black box

The tester gets a target and nothing else. No architecture notes, no documentation, no source code. They discover the system as an outsider would.

Grey box

The tester gets partial information — typically credentials, a description of the roles, an API specification, and answers to questions asked during the engagement. They do not get source code.

White box

The tester gets everything available: architecture diagrams, source code, configuration, design documents, and access to the people who built it.

The argument for black box, and what is wrong with it

The case usually made is realism: a real attacker knows nothing about your system, so a test that starts from nothing is more representative.

The premise is right and the conclusion does not follow. A real attacker also has unlimited time, no scope boundary, no rules of engagement, and no obligation to write anything down. You are not buying an attacker. You are buying ten or fifteen days of a specialist's attention, and the question is what those days are best spent on.

In a black box engagement, a meaningful share of them goes on discovery — enumerating what exists, working out the technology, mapping the roles by observation. That work is genuinely skilled. It is also work you could have eliminated with a document you already have, and every day spent on it is a day not spent looking for authorisation flaws.

The realism you are buying is realism about reconnaissance, which is the part of an attack that is cheapest for a real adversary and most expensive for you to purchase.

When black box is genuinely the right choice

Three cases, and they have a shape in common: the question being asked is about discovery itself.

• Validating your external perimeter. What can somebody find from the outside, and does it match your inventory? Here the discovery is the deliverable — and it routinely surfaces hosts nobody knew were exposed.
• Testing detection. If part of the point is whether your monitoring notices, information given to the tester changes the exercise. This shades into red teaming.
• A specific external assurance requirement that names it. Uncommon, but it exists.

Why grey box is the sensible default

For most engagements — an application, an API, an internal network — grey box gets the most findings per day. The tester is told what the system is for and who the users are, and spends their time on whether the rules hold.

Critically, grey box is what makes authorisation testing possible. Broken access control is consistently among the most common serious findings, and finding it requires knowing which records are supposed to belong to whom — which is information, not access. A tester who has not been told the role model can observe that an endpoint returned data, but not that it should not have.

When white box earns its cost

Source-level access changes what is findable. Some flaws are close to invisible from outside and obvious from inside: a race condition between two operations, a cryptographic mistake in key handling, a permission check that exists but is wrong in a case reached only by a particular sequence.

It is worth it when the assurance requirement is high, when the authorisation model is complex enough that reasoning about it beats probing it, or when the consequence of a missed flaw is severe. It costs more, because reading code takes time and the tester needs to understand the language and framework.

Note that a white box penetration test and a secure code review are not the same purchase. The first uses code to inform attacks against a running system; the second is a systematic review of the code itself. They find different things and are frequently confused in proposals, which is worth clarifying before signing.

What actually happens in practice

Most real engagements are grey box with a black box phase at the start — a few days working from outside to establish what is discoverable, then the information is handed over and the substantive testing begins.

This gets you the discovery finding, which is the genuinely valuable part of black box, without spending the whole engagement on it. If a proposal does not describe something like this, it is a reasonable thing to ask for.

The question to ask a vendor

Not "do you do black box testing", which every vendor answers yes to. Ask instead: given this system, what information would you want, and what would you do differently without it?

A tester who has thought about it will tell you what they would spend the first three days on in each case, and roughly what it costs you in coverage. One who has not will restate the definitions.

The related decision — how many accounts and at what privilege levels — is covered in preparing for your first VAPT. What each choice does to the price is in what moves the price of a penetration test.