Before a test starts, somebody has to decide how much the tester is told. The answer changes the cost, the length, and above all what you learn. There is no best option; there is an option that fits the question you are asking.
Black box - told nothing
The tester starts where an outsider starts: a domain name, maybe a company name. No credentials, no documentation, no source.
It answers one question honestly: what can somebody reach from the internet with no inside help? That is worth knowing, and it is the closest thing to a real opportunistic attack.
The cost is time. Days go on mapping what you could have described in an hour, and that is time not spent attacking. Anything behind a login may never be looked at, so a clean result can mean "the outside is solid" rather than "the application is solid".
Grey box - told what a user knows
The tester gets working credentials for each role, a description of the application, and the parts you are worried about. No source code.
This is the right default for most web applications, and it is what we recommend unless there is a reason not to. It covers the attack that actually happens most often: somebody who already has an account - a customer, a former employee, somebody who bought credentials - trying to reach what they should not.
It also finds the access-control problems that matter most, because the tester can log in as two different users and compare. That comparison is impossible without accounts.
White box - told everything
Source code, architecture diagrams, infrastructure access, time with your developers.
This finds the most, per day spent, because nothing is guessed. It reaches the code path that only runs for one customer configuration, and the flaw that is invisible from outside but obvious in the source.
What it does not tell you is how hard any of it would be to find from the outside. Use it where the consequences are serious enough that you want everything found regardless: payments, health data, authentication, anything handling money.
Picking one
- New public website or marketing site. Black or grey box. There is little behind a login to miss.
- Application with customer accounts. Grey box, with credentials for every role you have.
- Payments, health records, anything regulated. White box, and budget for a retest.
- Checking whether your monitoring works. None of these - that is a red team exercise, which is a different thing again.
One thing that is not optional
Whichever you pick, write the scope down and keep it with the report. In a year, when somebody asks why an issue was missed, "it was out of scope and here is the signed document saying so" is the whole answer. Without it, every finding that was never looked for becomes an argument.
Choosing between them
Which one should we buy if this is our first test?
Grey box, nearly always. You get credentials for each role into the tester’s hands on day one, so the whole budget is spent attacking rather than guessing, and the test covers the part of the application where your data actually lives. Black box is the right answer when the question is specifically "what is exposed to the internet", not when the question is "is this application safe".
Does black box testing prove we are secure if nothing is found?
No, and this is the most expensive misunderstanding in the field. A clean black box result means the outside held for the days we spent on it. Everything behind the login may never have been reached at all. If a clean result is going to be shown to a customer or a board, make sure the report says what was and was not tested.
Is white box testing just a code review?
No. A code review reads the source; a white box penetration test uses the source to attack the running system faster and more completely. The two complement each other, and for payment or health systems we would normally recommend both, in that order.
Can we change the approach once testing has started?
Within reason, yes, and it sometimes makes sense: a black box test that stalls on the perimeter is often worth converting to grey box so the remaining days are spent usefully. We would rather tell you that on day three than hand you a thin report on day ten.
Want this done on your own systems?
We scope the work in writing first, so you know exactly what will be touched and when.
Book a free consultation Back to the blog