Black Box, Grey Box, or White Box: Choosing a Penetration Testing Approach

Short answer: black box imitates an outside attacker who knows only the website address. Grey box gives the tester an ordinary user account, so access rights between users are tested as well. White box gives access to the source code and documentation for the most thorough examination. For most websites and applications that have user accounts, grey box is the most balanced starting point.

When ordering a penetration test, one of the first decisions is how much information to give the tester. This choice is often treated as a technical detail, yet it directly affects the kinds of flaws found, how long the test takes, and what you need to prepare.

Comparing black box, grey box, and white box

Aspect	Black box	Grey box	White box
Tester’s starting information	Only the website address	An ordinary user account and an overview of its features	Access to source code and documentation
What it imitates	An outside attacker who knows nothing yet	A registered user trying to go beyond their rights	A thorough examination with full knowledge
Flaws most visible	Login pages, public forms, configuration	Access rights and business logic between users	Flaws inside the code that are not visible from outside
Testing time	Part of it is spent mapping the target	More focused	Longest, because the code is reviewed too
What you prepare	An authorization letter and the target address	Test accounts for each user role	Repository access and a contact from the development team

Black box: the view of an outside attacker

Black box answers the question “what does a stranger on the internet see?”. The tester starts from zero, like an attacker who has no account yet. This approach is good for finding exposed configurations, admin pages that are easy to find, and public forms that do not validate input.

Its weakness is that part of the testing time is spent mapping the target, and features behind the login page are barely touched. Yet that is usually where the important data sits.

Grey box: a user trying to go beyond their rights

Grey box gives the tester an ordinary user account for each role, for example customer, staff, and approver. With that, the tester can check whether one user can see another user’s data, change an order that is not theirs, or run a function meant only for admins.

Flaws like these often slip past automated scanning because they depend on the application’s logic. Because the tester does not have to guess what can be given directly, the time goes into testing features, not looking for an entry point. That is why grey box is the starting point for most needs.

White box: examination with full knowledge

White box gives the tester access to source code and documentation, so flaws that are not visible from the website’s behavior, such as incorrect data handling behind the scenes, are found too. This approach is most suitable for systems that handle sensitive data or transactions.

It takes the longest, and you need to prepare repository access and someone from the development team who can answer the tester’s questions.

How to choose

1. Start from the biggest risk. If the main concern is an outside attack on a system that is mostly public, black box already answers it.
2. Are there user accounts and several roles? Choose grey box. Most data leaks between users are in this area.
3. Does it handle sensitive data or transactions, and can the code be opened? Consider white box.
4. Match it to your time budget. In the same amount of time, the more information the tester has, the deeper the flaws found.

What happens after testing

Whichever method is chosen, the value of testing lies in what is done afterward:

1. Severe findings are reported right away. Critical or high flaws do not wait for the final report, so they can be closed as soon as possible.
2. The final report contains each finding with its CVSS score, evidence, impact, and fix steps, ordered by severity.
3. Fixes are carried out by your development team or the vendor that holds the system.
4. A retest confirms that each flaw is truly closed, not just declared done. A rushed fix sometimes closes one path but opens another.
5. The next schedule. A system changes with every new feature, so testing should be repeated after a major release or on a regular basis.

One note: test results are confidential. The report is handed only to the parties agreed at the start, and the details of findings are never published.

How Legia does it

Currently, Legia’s penetration testing focuses on websites and web applications, with OWASP Top 10 and OWASP ASVS as references and CVSS to rate severity. The whole process generally takes 3 to 6 weeks, the method and limits are agreed in writing at the start, and a retest after fixes is included in the package. Service details are on the Penetration Testing page.

If you are not sure whether you need penetration testing or whether a vulnerability assessment is enough, first read Vulnerability Assessment or Penetration Testing.

Frequently asked questions

Sources

• OWASP Web Security Testing Guideowasp.org
• OWASP Top 10owasp.org

Asked to hand over security test results for an audit or a release? See Legia cybersecurity services, or schedule a consultation through the contact page.