The three terms describe one variable: how much the tester is told before they start. That sounds like a procurement detail. It is actually the single decision that determines which categories of finding are reachable at all.
Get it wrong and you can pay for a thorough, competent, well-documented engagement that was structurally incapable of finding the problem you actually have.
The three approaches side by side
| Black box | Grey box | White box | |
|---|---|---|---|
| Tester receives | The public URL | A test account, often the schema | Full source and architecture |
| Simulates | An external attacker | A malicious or compromised user | An insider, or a code review at attack depth |
| Reconnaissance cost | High — much of the time goes on mapping | Moderate | Low |
| Reaches business logic? | Only what is public | Yes | Yes |
| Reaches cross-account access? | No | Yes | Yes |
| Reaches credential storage? | No | Rarely | Yes |
| Typical first engagement | Yes | Second pass | Mature programmes |
Black box: what a stranger can reach
The tester starts where an attacker starts. No source code, no database, no account. Everything has to be discovered from outside.
The argument for it is straightforward: it is the honest simulation. It answers the question your board actually asks, which is what somebody on the internet could do to us right now. Nothing is assumed, so nothing is accidentally excluded by assumption.
It also finds a particular class of thing well. Exposed files, forgotten endpoints, development routes still answering in production, misconfigured edges — these turn up in black box work because the tester is systematically looking at everything reachable rather than at what the documentation says exists.
What black box cannot see
- Whether one account can read another account's data
- How passwords and sign-in codes are stored and compared
- Session fixation and idle timeout behaviour
- Any business logic behind a login or a paywall
- Per-account lockout thresholds — testing these from outside means locking out a real user
That list is not small. Broken object-level authorisation — one user reading another's records — has sat at or near the top of the API security risk lists for years, and black box testing without an account cannot reach it.
Grey box: what a logged-in user can reach
Grey box gives the tester a genuine account, and usually two. Two accounts is the important detail, because that is what makes cross-account testing possible: log in as A, take a request that returns A's data, and replay it as B.
It also compresses reconnaissance. Time spent guessing routes from outside is time not spent testing logic, and on a fixed budget that trade is usually worth making.
The obvious objection is that it is less realistic. In practice it is more realistic than it looks. Attackers routinely have accounts, because on most products anyone can sign up for one. And a compromised customer account is one of the most common real-world starting positions there is.
White box: the whole picture
Source code, architecture, sometimes the running infrastructure. This is where you find the things that are invisible from any amount of outside probing: a weak hashing algorithm, a race condition between two handlers, a permission check that exists on six endpoints and is missing on the seventh.
It costs more and needs more from your team. It suits organisations that have already closed the obvious external surface and want depth. Buying it first is usually a mistake — you would be paying for archaeology while your front door is open.
How to choose
A rough decision path that holds for most web applications.
- 1Never tested before, or a fixed compliance requirement to satisfy? Start black box. It establishes the external baseline and it is the easiest engagement to scope and justify.
- 2Application has accounts, roles or a paywall? Grey box, or black box followed by a grey box pass. If users can see each other's data, that is only testable with accounts.
- 3Handling payments, health data or anything regulated? Grey box minimum. Consider white box for the components that touch the sensitive path.
- 4Already run several tests and closed what they found? White box, or a red team exercise if you also want to test detection and response.
The combination that works well
Run black box first. It sets the baseline honestly, and it will find the configuration and exposure issues that are cheap to fix. Close those.
Then run a grey box pass with two disposable accounts created for the purpose. Not real customer accounts, and not a live administrator — testing lockout thresholds against a real administrator is how you take your own support team offline for an afternoon.
The second engagement is cheaper than the first, because the external surface is already mapped and already clean.
One thing to insist on either way
Whatever approach you buy, the report has to state which checks the method could not complete. A check that was not run is not a check that passed, and the two must not be allowed to look identical in the document.
If you commission black box testing, expect a limitations section naming cross-account access, credential storage and session lifecycle as unreached. If it is missing, ask for it. What a report should contain covers the rest of the structure.
Penetration Testing
Manual black box and grey box penetration testing for web applications and APIs. OWASP WSTG methodology, CVSS v3.1 scoring, and remediation re-testing included. Free scoping call with NEXHUB Technology.
See how we run it →