What is the difference between black box and grey box testing?

Black box means the tester receives only a hostname or IP range and must discover everything else, which spends engagement time on reconnaissance you could have supplied. Grey box means they receive credentials for each user role, architecture notes and API documentation, so the time goes into authorisation logic, privilege escalation and business logic abuse. Grey box is the sensible default for any application with a login.

Is black box testing more realistic?

Not in a meaningful sense. A real attacker has unlimited time, no report deadline, tolerance for failure, and may already hold credentials bought from stolen session logs or gathered by phishing. A tester has a fixed number of days. Withholding information gives you an attacker with less knowledge and less time than the real threat, which understates exposure rather than testing it. Black box is best used for discovery of unknown external assets.

Should you give a penetration tester your source code?

Yes, when the system is high value or the release is significant. Code access lets a tester locate the vulnerable sink directly and then work out which request reaches it, rather than probing inputs speculatively. It is especially effective for cryptographic mistakes, race conditions and authorisation checks present in one path and missing in another. The real constraints are confidentiality handling and finding a tester fluent in your framework, not realism.

How many test accounts should you provide?

At least one per role, and two per role where possible. Vertical privilege escalation testing needs both a standard and an administrative account to demonstrate the crossing. Horizontal testing, where one customer reaches another customer's data, is impossible with a single account because there is no second identity to target. In multi-tenant products, an account in each of two tenants is the most valuable pair of credentials you can supply.

What is assumed breach testing?

The tester begins with a foothold, such as a shell inside a container or an ordinary domain account, and works outward to establish what that position reaches. It skips the question of whether initial access is possible, which is usually agreed anyway, and measures blast radius instead. In container and cloud estates this is the highest value framing, because the significant risk is what an over-permissioned workload identity can reach after compromise.

Can you combine a configuration review with a penetration test?

Yes, and in cloud or Kubernetes environments it is better value than either alone, because over-permissioned roles, mounted tokens with cluster-wide rights and permissive network policy are visible in configuration within minutes but take a day to establish by probing. Keep the outputs distinguishable in the report: findings that were also proved through exploitation deserve different priority from findings that are so far only theoretical.

Penetration testing guide

Black box, grey box and white box testing compared

Black box testing is the default request and it is rarely the best value. Withholding information from your tester does not make the test more realistic, because a real attacker has unlimited time and no reporting deadline, and your tester has five days. Most engagements should be grey box: credentials, an architecture diagram and a brief, so the time goes into finding flaws rather than rediscovering your URL structure. Black box has one legitimate use, and it is narrower than the market implies.

Why is black box testing usually the weaker choice?

Because you are paying a specialist to spend the first part of a fixed engagement reconstructing information you already have. Enumerating endpoints, guessing parameter names and mapping the application takes real time, and every hour spent there is an hour not spent probing authorisation logic. The findings that emerge from black box work are disproportionately the ones a scanner would also have found, because those are what surfaces from the outside quickly.

The realism argument does not hold on inspection. An attacker interested in your organisation has weeks, does not have to write a report, and can afford to be noisy or to fail repeatedly. They may also already hold credentials bought from an infostealer log or harvested by phishing. Simulating an attacker with less knowledge than a real one has, under a tighter time limit, understates rather than tests your exposure.

There is a practical tell. If a black box report opens with a long reconnaissance section and closes with findings about headers and TLS configuration, the constraint you imposed consumed the budget. The same money spent grey box would have reached the authorisation layer.

What does each level of access actually mean?

The three terms describe what the tester is given, not how hard they try. The distinctions matter contractually, because they determine what the report can plausibly cover and what a clean result actually proves.

Approach	Tester receives	Strongest at finding	Sensible use
Black box	A hostname or an IP range only	External exposure, forgotten hosts, weak edge configuration	Perimeter validation and attack surface discovery
Grey box	Credentials for each role, architecture notes, API docs	Broken access control, privilege escalation, logic abuse	The default for any authenticated application
White box	Source code, configuration, build pipeline, cloud read access	Injection sinks, cryptographic misuse, unreachable-looking paths	High-value systems and pre-release assurance
Assumed breach	A foothold on a host or inside a container	Lateral movement, over-permissioned identities, blast radius	Container and cloud estates, internal networks
Red team	An objective and rules of engagement, nothing else	Gaps in detection and response, not vulnerability coverage	Organisations with a working monitoring function

Does giving a tester source code make the test unrealistic?

No, it makes it more thorough, and the two are being confused. Source access lets a tester see the sink before hunting for the source: they can find the query built by string concatenation, then work out which request reaches it, rather than probing thousands of inputs hoping to hit it. The finding that results is the same finding, arrived at faster and with a more precise fix recommendation.

Code access is particularly effective on things that are close to invisible from outside. Cryptographic mistakes such as a predictable token seed or a signature check that compares only the prefix, race conditions in payment flows, and authorisation decisions taken in one code path but omitted in another are all much cheaper to find in code than to guess at through a browser.

The realistic objection to white box testing is not realism but cost and confidentiality. It requires the tester to be competent in your language and framework, which narrows your supplier options, and it means your code leaves your environment or the tester works inside it. Both are manageable. Neither is a reason to prefer ignorance.

How does this apply to containers and cloud?

In a container estate the useful default is assumed breach, which is a form of grey box aimed at a specific question: what happens after one workload is compromised. The tester starts with a shell in a pod, which is where an application flaw would put an attacker anyway, and works outward. That skips the part everyone already agrees is possible and spends the time on the part nobody has measured.

White box in this context means read access to manifests, Helm charts, Terraform and IAM policy rather than only application source. Over-permissioned service accounts, a role with wildcard permissions, a mounted token with cluster-wide rights and a network policy that permits everything are all visible in configuration in minutes, and can take a day to establish by probing. Combining a configuration review with hands-on testing is materially better value than either alone.

Keep the two outputs separate in the report. Configuration review findings are cheap to produce and easy to dismiss as theoretical, so the ones that were also proved by exploitation should be marked as such. That distinction is what lets your engineers prioritise correctly rather than treating a wildcard IAM policy and a demonstrated escape to the node as equivalent.

Why do you need credentials for every role?

Because most access control failures only appear when one role reaches something belonging to another, and a single test account cannot demonstrate that. To test whether a standard user can perform an administrative action, the tester needs both accounts. To test whether tenant A can read tenant B's data, they need an account in each tenant, and this is the single most valuable pair of credentials you can supply in a multi-tenant product.

Two accounts per role is better than one, for the same reason. Horizontal privilege problems, where one customer reaches another customer's records by changing an identifier, are invisible with a single account because there is no second identity to reach towards.

This is also where engagements lose days. Provisioning accounts across roles and tenants requires someone with administrative rights and a reason to prioritise it, and if that person is not identified before the start date the tester works with whatever they have. Agree the account matrix in the scope, name the person who creates it, and have it ready before day one.

Which should you buy?

Grey box for almost everything, with black box added only where discovery is the point. A useful pattern is a short unauthenticated phase to check what is exposed and whether anything unexpected is reachable, followed by the bulk of the engagement authenticated with full role coverage. That gets you the perimeter answer without sacrificing depth.

Choose white box when the consequences of a missed flaw are severe, when the application handles money or health data, when you are about to ship a significant release, or when a previous test found something subtle and you want to know whether the same class of mistake exists elsewhere. Also choose it when you are paying for a specialist in your stack, because that competence is wasted on black box work.

The test to run this week: look at your last report and count the findings that required valid credentials to discover. If the answer is none or nearly none, either your tester had no accounts or your application has no authenticated surface worth mentioning. The first is a scoping failure you can fix at the next engagement for no extra cost.

Common questions

What is the difference between black box and grey box testing?: Black box means the tester receives only a hostname or IP range and must discover everything else, which spends engagement time on reconnaissance you could have supplied. Grey box means they receive credentials for each user role, architecture notes and API documentation, so the time goes into authorisation logic, privilege escalation and business logic abuse. Grey box is the sensible default for any application with a login.
Is black box testing more realistic?: Not in a meaningful sense. A real attacker has unlimited time, no report deadline, tolerance for failure, and may already hold credentials bought from stolen session logs or gathered by phishing. A tester has a fixed number of days. Withholding information gives you an attacker with less knowledge and less time than the real threat, which understates exposure rather than testing it. Black box is best used for discovery of unknown external assets.
Should you give a penetration tester your source code?: Yes, when the system is high value or the release is significant. Code access lets a tester locate the vulnerable sink directly and then work out which request reaches it, rather than probing inputs speculatively. It is especially effective for cryptographic mistakes, race conditions and authorisation checks present in one path and missing in another. The real constraints are confidentiality handling and finding a tester fluent in your framework, not realism.
How many test accounts should you provide?: At least one per role, and two per role where possible. Vertical privilege escalation testing needs both a standard and an administrative account to demonstrate the crossing. Horizontal testing, where one customer reaches another customer's data, is impossible with a single account because there is no second identity to target. In multi-tenant products, an account in each of two tenants is the most valuable pair of credentials you can supply.
What is assumed breach testing?: The tester begins with a foothold, such as a shell inside a container or an ordinary domain account, and works outward to establish what that position reaches. It skips the question of whether initial access is possible, which is usually agreed anyway, and measures blast radius instead. In container and cloud estates this is the highest value framing, because the significant risk is what an over-permissioned workload identity can reach after compromise.
Can you combine a configuration review with a penetration test?: Yes, and in cloud or Kubernetes environments it is better value than either alone, because over-permissioned roles, mounted tokens with cluster-wide rights and permissive network policy are visible in configuration within minutes but take a day to establish by probing. Keep the outputs distinguishable in the report: findings that were also proved through exploitation deserve different priority from findings that are so far only theoretical.