Black box, grey box, white box: which to choose and why

When you commission a pentest, you'll be asked what level of information you want to provide to the tester. This choice (black box, grey box, or white box) determines what the engagement can cover, at what depth, and what type of risk it will simulate. There is no universal right answer.

Black box: the exposed surface seen from outside

In black box, the tester receives nothing beyond the target URL or IP address. No account, no documentation, no information about the stack or the organisation. They start with the same starting point as an external attacker who knows nothing about you.

The advantage: it's the closest scenario to an opportunistic external attack: someone who targets your domain because they found it on the internet. The vulnerabilities that surface are those exploitable by anyone, with no prior knowledge.

The limitation: on a short engagement, a large share of the time goes into reconnaissance: mapping endpoints, understanding the architecture, identifying attack surfaces. On a two-day pentest, that's potentially half a day spent understanding what you could have explained in 10 minutes.

Grey box: the most common approach

In grey box, the tester receives some information: a standard user account (sometimes multiple privilege levels), sometimes an overview of the technologies used or the general architecture. No code, no database, no server configurations.

It's the most common approach because it offers the best balance between realism and depth of coverage. It simulates an attacker who has done their research, or an employee, contractor, or legitimate user with bad intentions.

In practice, it's also the level that allows the most ground to be covered in limited time. It avoids the full reconnaissance phase while keeping a realistic attack perspective.

White box: depth above all

In white box, the tester has access to everything: source code, technical documentation, architecture, sometimes direct access to configuration environments. The objective is no longer to simulate an external attacker: it's to analyse the security of the system in depth, from the inside.

White box allows finding vulnerabilities that dynamic tests would consistently miss: flawed authorisation logic in rarely executed code paths, hardcoded secrets in files rarely exposed externally, dependencies with critical CVEs in internal components not reachable from outside.

It takes longer, demands more, and requires trust in the confidentiality of shared information. It's also the only approach that allows a structured security code review.

How to choose based on your situation

A simple heuristic: if this is the application's first pentest, start with grey box. If you already have a testing history and want to go deeper, consider white box on the most critical components. Black box makes sense as a complement, to validate your external exposure, but rarely as the primary approach on a short engagement.

Available time matters too. On a one-day engagement, black box will be low-yield. On a week or more, it becomes more relevant: the reconnaissance time pays off.

A well-covered grey box beats a black box that spends its day guessing your tech stack.

The choice of information level is not purely a technical decision, it's also a decision about what you want to learn from the engagement. Simulate the most realistic external attacker possible, or find the maximum number of vulnerabilities in the available time? Both objectives are legitimate. They simply call for different approaches.