# Black box vs grey box vs white box penetration testing

Source: https://penetrationtestservices.com/guides/black-box-grey-box-white-box-testing/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

How black box, grey box and white box penetration tests differ, what each costs you in time and depth, and a decision table to choose one.

> **Short answer:** Black box testing gives the tester no inside knowledge. Grey box gives partial knowledge, usually test accounts and API docs. White box gives full access, including source code. For most web apps and APIs, grey box finds more per hour of testing. Choose black box to see the outside view, white box for the deepest review.

Black box, grey box and white box describe how much the tester knows before the test starts. Black box means no inside knowledge. Grey box means partial knowledge, usually accounts and documentation. White box means full knowledge, including source code and architecture.

The type changes what the tester can reach in a fixed time. The goal is the same for all three: find real weaknesses and prove them.

## What is black box penetration testing?

In a black box test, the tester starts with only a target, such as a domain name. There are no accounts and no documents. The tester must find everything from the outside.

This is the view of an anonymous attacker, and it answers one question: what can a stranger do to your app?

Black box has limits. Most of a SaaS app sits behind a login, so without an account much of the app stays untested. The tester also spends time on discovery that a list of endpoints from you would shorten.

Many black box tests still need accounts. If sign-up is open and in scope, the tester can create them. If not, the owner should provide test accounts, and the test becomes grey box.

## What is grey box penetration testing?

In a grey box test, the tester gets some inside knowledge. The usual set is:

- Two or more test accounts per role, in separate tenants if your app is multi-tenant.
- API documentation, an OpenAPI file or a Postman collection.
- A short description of the main user flows.
- Contact details for someone who can answer questions.

Grey box is the best default for web apps, APIs and SaaS products. Most serious flaws in these systems sit behind authentication: broken access control, tenant leaks, role bypass and logic errors. Proving them takes at least two accounts, because one account cannot show that Alice can read Bob's data.

## What is white box penetration testing?

In a white box test, the tester gets full access: source code, architecture diagrams, configuration and often a developer to ask. Some teams call this a "crystal box" test.

White box finds the most issues per hour, because the tester reads the code instead of guessing. The tester reads the authorization code, finds the route that skips a check, and proves the flaw on the running app.

White box costs more preparation and more of your engineers' time. Code review also takes tester hours that a smaller budget may not cover. Sharing code needs trust, a signed agreement and a plan for how the code is stored and deleted.

## How do the three types compare?

| | Black box | Grey box | White box |
|---|---|---|---|
| Tester knowledge | None | Accounts, docs, flow notes | Code, architecture, configuration |
| Models | Anonymous outsider | User or partner with an account | Insider or full audit |
| Depth behind login | Low | High | Highest |
| Setup work for you | Minimal | Moderate: accounts, docs | Highest: code access, briefings |
| Time spent on discovery | Most | Some | Least |
| Good at finding | Exposed services, weak login, public leaks | Access control, tenant isolation, logic flaws | Hidden routes, missing checks, unsafe code paths |
| Weak at | Authenticated flaws | Flaws only visible in code | Can over-focus on code and miss deployment issues |

## Which type should you choose?

| Your situation | Suggested type | Reason |
|---|---|---|
| Public marketing site, no login | Black box | Little hides behind the front door |
| SaaS app with roles and tenants | Grey box | You need accounts to test isolation |
| API used by a mobile app or partners | Grey box | Docs and tokens save time and widen coverage |
| First pentest before launch, small team | Grey box | Best result for the time spent |
| Customer asked for an "external" test | Black box, then grey box | Meets the wording and still reaches the app |
| Payment, health or admin-heavy logic | White box, or grey box plus code review | Hidden logic is costly if wrong |
| You want to check detection and response | Black box, or a red team | See the [red team guide](/guides/red-team-vs-penetration-testing/) |
| Retest of earlier findings | Match the first test | Results stay comparable |

If you are unsure, start with grey box and add a black box phase at the front if you want one. You rarely regret giving the tester accounts.

## Does a black box test mean the tester has fewer rules?

No. The same authorization and rules apply to all three types. The tester stays in scope, uses test data, and stops when a stop condition occurs. The [rules of engagement](/guides/penetration-testing-rules-of-engagement/) guide lists them.

## What does the type mean for the ASVS and other standards?

OWASP's ASVS says Level 1 is "not necessarily penetration testable by an external tester without internal access to documentation or code." A pure black box test cannot check every requirement of a verification standard, so plan for grey or white box access if your goal is to verify against one.

## What should you prepare for each type?

Black box needs the least. Give the target list, the test window and a contact. Grey box adds accounts and docs. White box adds a repository or code archive.

The full checklist is in [how to prepare for a penetration test](/guides/how-to-prepare-for-a-penetration-test/).

## Worked example: choosing for a SaaS startup

> **Demonstration only:** This is a demonstration. No real customer system was tested. Harbor Notes is a fictional note-taking SaaS. It has three roles (owner, editor, viewer), a public REST API and a billing page. A large customer asks for a pentest report before it signs.
The team has a small budget and a short deadline. Their questions:

1. Can one customer read another customer's notes? This needs two tenants and accounts. It points to grey box.
2. Can a viewer edit a note? This needs one account per role. Grey box again.
3. Is anything exposed to the internet that should not be? A short black box phase answers this.

The plan: a short black box discovery phase, then grey box with six accounts (three roles in two tenants) and the OpenAPI file. No source code is shared. The written scope states this, so the customer's reviewer can see how deep the test went.

If Harbor Notes later handles payments in its own code, the team can add a white box phase for the billing logic. Our [SaaS penetration testing](/saas-penetration-testing/) page explains the two-tenant method. For web apps in general, see [web application penetration testing](/web-application-penetration-testing/).

## Questions

### Which type is the most realistic?

Black box is closest to an outside attacker with no access. But real attackers also buy or steal accounts, and they have time. Grey box models an attacker who already has an account, which is a common case for SaaS.

### Is white box testing the same as a code review?

No. A code review reads source without running the app. A white box pentest gives the tester the code and then attacks the running system. The code helps the tester aim, and the live tests prove the impact.

### Can I mix the types in one project?

Yes. A common plan starts with a short black box phase, then moves to grey box with accounts. Agree the phases in the written scope so both sides know what is expected.

### Does the type change the report?

The report format stays the same. The scope section states what the tester knew. That context helps you judge what the results mean.

## Sources

- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final)
- [OWASP Web Security Testing Guide](https://wstg.owasp.org/)
- [OWASP ASVS 5.0.0: What is the ASVS (Level 1 and penetration testing)](https://github.com/OWASP/ASVS/blob/v5.0.0_release/5.0/en/0x03-What-is-the-ASVS.md)