Every penetration test starts with a handover. Some teams give testers nothing but a company name. Others hand over admin accounts, architecture diagrams and the code repository. Where you sit on that range changes what the test can find in the days you have paid for, so it deserves a conscious choice rather than a default.
What each approach means in practice
The labels describe how much the testers are told before they begin. They are not quality grades; each fits a different question.
| Black box | Grey box | White box | |
|---|---|---|---|
| Testers receive | Target names or IP ranges only | User accounts per role, API docs, basic architecture | Source code, design docs, config, admin access |
| Simulates | An outsider with no foothold | A customer, partner or insider with normal access | A well-informed attacker or a thorough design review |
| Main strength | Shows what is visible from outside | Strong coverage of authorisation and business logic | Finds subtle logic, crypto and design flaws |
| Main weakness | Time spent on discovery; limited depth | Assumes some initial access exists | Needs more client preparation and trust |
| Typical use | External perimeter, red team start points | Most web, API and mobile tests | High-risk apps, crypto, payment logic |
Black box testing
In a black box engagement, testers know what an attacker on the internet would know. They map hostnames, identify technologies, find login pages and try to get in. That is valuable for an external network pentest, where the whole point is to see the perimeter as strangers see it.
The weakness is time. A real attacker can spend months probing. A tester has a few days. If most of those days go on discovering an API that your team could have described in a paragraph, you have paid for reconnaissance rather than findings. Black box tests of authenticated applications often stop at the login page, which says little about what a signed-up user could do.
When to choose it
- You want an outsider's view of your internet-facing footprint
- You are checking what has leaked or been forgotten, such as old subdomains
- It is the opening phase of a red team assessment where realism matters more than coverage
Grey box testing
Grey box is the working default for application testing. Testers get accounts for each role, usually two per role so they can try to cross from one user's data to another's. They often receive an API specification, a short architecture note and a list of features that matter most.
This is where the most damaging application bugs tend to live. Broken object-level authorisation, privilege escalation between roles and business logic abuse only show up once you are logged in. Grey box testing focuses tester time on exactly those areas.
When to choose it
- Most web application, API and mobile app tests
- Internal network tests that start from a standard employee device
- Any compliance-driven test where you need broad coverage in a fixed budget
White box testing
White box testing removes the guesswork. Testers read the code paths behind a feature, see how tokens are generated, check how permissions are enforced in the data layer and confirm whether a suspicion is real. It pairs naturally with a secure code review, and many teams run both in one engagement.
The cost is preparation. You need to share code securely, explain the build, and sometimes give access to configuration or infrastructure-as-code. In return, white box testing finds issues that would take a black box tester far longer to stumble upon, if they ever did.
When to choose it
- Payment, authentication or cryptographic code where a subtle flaw is costly
- Applications that have already passed several grey box tests
- Before a major launch, when design changes are still cheap
Choosing for your situation
Three questions narrow the decision quickly:
- What is the threat you care about? Anonymous outsiders favour black box for the perimeter. Customers, partners and staff favour grey box.
- How many days can you fund? Fewer days mean you should give testers more information so they spend those days finding problems.
- What has been tested before? A first test often starts grey box. Mature applications benefit from white box depth.
Hybrid approaches are common. An engagement can begin black box for a day to see what is exposed, then switch to grey box once credentials are handed over. Agree any switch points in the scope so nobody is surprised.
A sensible grey box handover
If you settle on grey box, a short handover pack saves days. Include:
- Two accounts for each user role, including at least one administrator
- An API specification or collection, even if it is slightly out of date
- A one-page description of the main workflows and the data that matters most
- Known issues already on your backlog, so testers do not spend time reporting them again
- Any areas you are particularly worried about
None of this makes the test easier to pass. It simply lets testers start where an informed attacker would, rather than at the front door.
Myths worth dropping
"Black box is the only realistic test"
Attackers buy or phish credentials every day. Starting with valid access is often the most realistic assumption you can make.
"Giving testers information is cheating"
The goal is to find weaknesses before someone else does. Withholding information just means paying testers to learn what your team already knows.
"White box replaces penetration testing"
Reading code finds many issues, but running the application finds configuration, deployment and integration problems that code alone cannot reveal. The two complement each other.
If you are weighing a time-boxed test against an open-ended programme, our comparison of penetration testing and bug bounties covers that choice.
Frequently asked questions
Is black box testing more realistic?
It mimics an outsider with no inside knowledge, but real attackers have months; testers have days. Grey box usually gives a more realistic picture per tester-day because it skips time spent on discovery.
Does white box testing mean you need our source code?
Usually yes, along with architecture documents and configuration. It pairs well with a secure code review and tends to uncover logic and design flaws that black box testing misses.
Not sure which approach fits? Request a quote and we will recommend a knowledge level for your web, API or code review engagement, or estimate effort first with the cost calculator.