Black box, white box and grey box testing - the differences

Black box testing is a penetration testing approach in which the tester has no prior knowledge of the system - no source code, no network diagrams and no credentials - and therefore simulates an attacker targeting your company from the outside. White box testing is the opposite: the tester is given full visibility into the code, architecture and configuration. Grey box testing sits in the middle, where the tester has partial knowledge, most often a user account or basic documentation.

Choosing between these three approaches is not a minor technical detail. It directly determines what you will learn from the test, how long the test will take and how much it will cost. Below we explain how each approach works, where it makes sense and how to choose the right one for your organization, whether you run a business in Mostar, a bank in Sarajevo or an e-commerce operation that serves the entire region.

What is black box testing?

In black box testing, the tester approaches the system like a real external attacker: they know only what any anonymous internet user knows, usually just the company name or domain. They have no access to source code, network diagrams or internal accounts. The goal is to answer a practical question: how far can someone attacking us from the outside get, without any help from the inside?

A typical black box test flows as follows:

• Reconnaissance: gathering publicly available information such as DNS records, subdomains, exposed services, data from previous breaches and employee information from LinkedIn.
• Scanning and enumeration: mapping open ports, service versions and the technologies the application uses.
• Vulnerability discovery: identifying weaknesses such as outdated components, misconfigurations or vulnerable web forms.
• Exploitation: attempting to exploit the weaknesses found in order to prove real impact.
• Reporting: documenting the findings together with remediation recommendations.

The main advantage of the black box approach is realism, because the result most faithfully reflects what your company is exposed to in the real world. The main drawback is coverage: since the tester starts from scratch, part of the time goes into discovering information that a white box tester would already have. Vulnerabilities hidden deep in the code, or in parts of the application that an external attacker never reaches, may go undetected. Black box testing therefore gives an accurate snapshot of external exposure, but not necessarily a complete picture of every weakness.

What is white box testing?

White box testing (also known as clear box or glass box) goes in the opposite direction. The tester receives everything: source code, architecture documentation, network diagrams, credentials and sometimes a conversation with the development team. The approach is transparent and thorough.

Because the tester sees the inside of the system, they can review logic that a black box test would never reach, for example how input data is processed in a back-end function, how privilege levels are arranged or where cryptographic keys are stored. This is the best approach when you want maximum depth and coverage, for instance before a new application goes to market or when auditing a critical system.

The price of that depth is twofold. First, a white box test requires more time and cooperation from your team, because someone has to prepare access and answer questions. Second, because the tester knows too much, the result does not necessarily reflect what a real attacker without insider information would manage to achieve. In other words, white box answers the question how secure are we internally, not how easy are we to attack from the outside.

What is grey box testing?

Grey box testing combines the practicality of both approaches. The tester is given partial knowledge, typically one or more user accounts, basic documentation or limited insight into the architecture, but not the full source code. This approach simulates two common scenarios very well: an attacker who has already obtained valid credentials (for example through phishing) and a malicious or compromised employee.

In practice, grey box is the most common choice for web applications and internal networks because it offers a good balance of realism and coverage. The tester does not spend days on reconnaissance from scratch, yet still approaches the system from a position close to a real threat. Both horizontal escalation (can one user see another user's data) and vertical escalation (can an ordinary user gain administrator privileges) are checked, and these are questions that are directly relevant to most companies in BiH and the wider region.

Comparison: black box vs white box vs grey box

Criterion	Black box	White box	Grey box
Tester's level of knowledge	No knowledge	Full knowledge	Partial knowledge
Simulates	External attacker	Internal audit / development	Attacker with access or an insider
Coverage	Lower (external only)	Highest	High
Realism	Highest	Lower	High
Time and cost	Medium	Highest	Optimal
Cooperation required from your team	Minimal	High	Moderate

Same system, three approaches: a concrete example

To make the difference tangible, imagine an internal order management web application belonging to a distributor from Mostar. The same application tested in three ways will produce three different pictures.

• Black box: the tester is given only the URL of the login page. Time is spent discovering hidden paths, testing the login form for weak passwords and attempting to bypass authentication. If the login is well protected, the tester may never reach a vulnerability that exists behind it, but in return it faithfully shows how hard it is to get in from the outside.
• Grey box: the tester is given an ordinary user account. Now they check whether that account can view or modify the orders of other clients (insecure direct object reference), whether they can change their own role to an administrator role and how the application behaves with manipulated requests. Considerably more is uncovered, because the test starts behind the login.
• White box: in addition to an account, the tester receives the source code. They can read how session tokens are generated, where SQL queries are built by concatenating strings and whether the password is stored with a secure algorithm. They also find weaknesses that are hard to spot from the outside but that, under certain conditions, could become a serious problem.

The lesson of the example: the same vulnerability can be invisible in one approach and obvious in another. The choice of approach is therefore not a question of a better or worse test, but of the question you want answered.

Methodologies and standards behind testing

Regardless of the chosen approach, serious penetration testing relies on recognized methodologies, not on an arbitrary sequence of tools. The most commonly used are:

• The OWASP Testing Guide and OWASP Top 10 are the reference framework for testing web applications, covering the most common categories of vulnerabilities such as injection, weak authentication and misconfiguration.
• PTES (Penetration Testing Execution Standard) describes the phases of an engagement, from preparation and information gathering to exploitation and reporting.
• NIST SP 800-115 provides technical guidance for security testing and assessment that many organizations use as a foundation.

These methodologies ensure that the test is repeatable and that it covers the relevant risk categories, which is especially important if you need to present the results to an auditor, a partner or as part of preparation for ISO 27001. Black box, white box and grey box are not a substitute for methodology, because they determine how much knowledge the tester brings in, while the methodology determines how the work is carried out systematically.

What you receive in the report and how remediation works

A test only has value once the findings are turned into concrete fixes. A quality penetration testing report should contain an executive summary (in business language, without technical jargon), a detailed technical description of each vulnerability, a severity assessment, proof of exploitability and clear remediation recommendations. Severity is most often rated according to the CVSS system, which helps the team set priorities, so the issues that are both easy to exploit and high impact are addressed first.

After fixes are applied, a retest is recommended to confirm that the vulnerabilities are genuinely closed and that the fix has not accidentally opened a new weakness. For companies and businesses that take security seriously, penetration testing is not a one-off event but is repeated periodically and after significant changes to the system.

How to choose the right approach

There is no universally best approach, because the right choice depends on which question you want answered and what the goal of the test is. A few practical guidelines:

Choose black box when…

You want to assess external exposure and see how your company looks from the perspective of a real attacker on the internet. Black box testing makes sense for an annual perimeter review, before or after major changes to publicly accessible systems, and when you want a test that does not burden your team with preparation.

Choose white box when…

Security is critical and you are looking for maximum depth, for example with financial applications, healthcare systems or software that processes sensitive data. White box is also a logical part of a secure development lifecycle, where the code is reviewed before production.

Choose grey box when…

You are looking for the best balance of coverage, realism and cost, which is the case for most web applications and internal networks. Grey box is also the natural choice when you want to know what a compromised user account or a disgruntled employee could do.

In many serious engagements the approaches are combined: a black box phase to assess external exposure, followed by a grey or white box phase for an in-depth analysis of the internals. If you are not sure what you need, it helps to start from a clear definition of the goal and scope. Our penetration testing questionnaire helps you arrive at the right scope through a few questions, without unnecessary cost.

How NeoBit approaches testing

At NeoBit, a cyber security company from Mostar, we tailor the methodology to the actual risk and the client's objectives instead of offering a one-size-fits-all package. For companies and businesses in BiH and the region, this means in practice a clearly defined scope, a repeatable methodology and a report that your team can genuinely use for fixes, rather than just a long list of findings without context.

Penetration testing is only one part of the bigger picture. Continuous monitoring through the Guardian 360 SOC (MDR), incident response and preparation for ISO 27001 round out an organization's security posture. You can learn more about how we approach each of these areas on the page covering our services and offerings.

Frequently asked questions

Is black box testing enough for my company?

It depends on the goal. Black box testing answers the question of how exposed you are to an external attacker very well, but due to its limited coverage it may miss vulnerabilities hidden deeper in the system. For a more complete picture, most companies combine black box with a grey or white box phase.

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

A grey box tester has partial knowledge, usually a user account and basic documentation, and simulates an attacker with access or an insider. A white box tester has full visibility, including the source code, so they can review internal logic that grey box does not reach. White box provides greater depth, while grey box provides greater realism at a lower cost.

How long does penetration testing take?

The duration depends on the scope, the approach and the complexity of the system. A smaller black box test of a web application can take a few days, while an extensive white box engagement on a complex system can take several weeks. The exact timeframe is defined after a discussion about scope and objectives.

How do I choose the right approach for my organization?

Start from the question you want answered: are you interested in external exposure (black box), maximum depth and code security (white box), or a realistic attack scenario with access and good coverage (grey box)? If you are not sure, feel free to contact us and we will help you define the scope.

Related guides: Cyber security in BiH - the complete guide · Penetration testing vs vulnerability scanning - which to choose · OWASP Top 10: the most common web vulnerabilities explained