Fundamentals
Black box vs gray box vs white box penetration testing
Published Updated 4 min read
The short answer
Black box, gray box and white box describe how much the testers know before they start: nothing beyond a target name, partial knowledge such as user accounts and documentation, or full access including source code and architecture. More knowledge means less time spent rediscovering what you could have told them, and more time finding real weaknesses. For most companies buying a time-boxed test, gray box gives the best coverage per hour.
What do black box, gray box and white box mean?
The terms describe the information and access the testers are given, not the techniques they use.
- [Black box testing](/glossary#black-box-testing): testers start with little more than a company name, a domain or an application URL. They see only what any outsider can see.
- [Gray box testing](/glossary#gray-box-testing): testers receive partial knowledge, typically user accounts at one or more privilege levels, API documentation and a high-level architecture overview.
- [White box testing](/glossary#white-box-testing): testers have full knowledge, such as source code, infrastructure configuration, cloud read access and direct conversations with engineers.
You will also see the terms opaque box, translucent box and clear box used for the same idea. In practice these are points on a spectrum, and one engagement can mix them: for example a black box look at the external perimeter, then gray box testing of the application.
How do the three approaches compare?
| Black box | Gray box | White box | |
|---|---|---|---|
| What testers get | Target name or URL only | Accounts, docs, some architecture | Code, configuration, full access |
| Simulates | An outside attacker with no inside help | A user, customer or attacker with stolen credentials | An insider or an attacker who has already got deep access |
| Coverage in a fixed budget | Lowest: time spent on discovery | High: time spent on logic and access control | Highest: can trace issues in code |
| Finds access control flaws | Rarely, without accounts | Well, with two or more accounts per role | Well, and can find the cause in code |
| Realism of attacker view | Highest | High for most real attacks | Lower: real attackers rarely start with code |
| Effort required from you | Minimal | Create accounts, share docs | Share code, give access, answer questions |
| Best for | Testing the external perimeter and what leaks publicly | Most web apps, APIs and SaaS products | High-risk code, cryptography, complex authorization |
Is black box testing more realistic?
It is more realistic about the starting point, but not always about the outcome. A real attacker has unlimited time; a black box tester has a few days. Much of that time goes to discovery work you could have answered in an email, such as which subdomains exist and how the login works.
Black box testing also has a structural blind spot: most of the serious weaknesses in modern applications sit behind a login. Without accounts, testers cannot check whether one customer can reach another's data, and that is one of the most common and damaging classes of flaw. The Open Worldwide Application Security Project (OWASP) ranks broken access control first in the current 2025 edition of its Top 10 for web applications, and broken object level authorization first in the OWASP API Security Top 10.
Black box is the right choice when the question is specifically what an outsider can see and reach, as in external penetration testing or attack surface discovery.
Why is gray box often the efficient choice?
Gray box testing assumes what is usually true: attackers get accounts. Many products let anyone sign up. Credentials leak through phishing, reuse and malware. A former employee or a curious customer already has a login. Testing from that position covers the risks that matter most for a SaaS business.
- Testers spend their hours on business logic and authorization instead of rediscovering your login flow.
- API documentation lets them reach endpoints a crawler would never find, including old or undocumented versions.
- Accounts at different privilege levels let them test privilege escalation and cross-tenant access directly.
- Results are easier to reproduce, because the starting conditions are known.
The minimum useful gray box setup for a multi-tenant product is two accounts per role, in two different tenants. See how to prepare for a penetration test for the full checklist.
What is credentialed testing?
Credentialed (or authenticated) testing means the testers, or their tools, log in. For applications, that is the gray box setup above. For networks and infrastructure, it usually means giving a scanner or tester an account that can read system configuration, so it can check installed software versions, missing patches and insecure settings from the inside instead of guessing from the outside.
Credentialed checks typically produce more accurate results and fewer false positives, because they read the real configuration. Use dedicated accounts with the least privilege needed, record them in the rules of engagement, and disable them when the test ends.
When is white box testing worth it?
White box testing is worth the extra effort when a weakness would be very costly and hard to find from outside: complex permission models, payment or money movement logic, custom cryptography, or authentication code you wrote yourself. With code in hand, testers can find a flaw once and trace every place the same pattern appears, which also makes fixes more complete.
It is not a substitute for testing the running system. Configuration, deployment and infrastructure issues often only show up live. Many teams pair a gray box test of the running application with targeted code review of the riskiest parts, and use static analysis in their own pipeline for broad code coverage.
How do you choose the right approach?
Start from the question you need answered:
- "What can a stranger on the internet find and exploit?" Black box against the external attack surface.
- "Can a customer or a stolen account reach other customers' data?" Gray box with multiple accounts and tenants.
- "Is our authorization or payment logic sound everywhere?" White box, or gray box plus code review of those components.
- "Do we meet a compliance or customer requirement?" Usually gray box, with scope set by the standard. See penetration testing for compliance.
If budget is fixed, more information almost always buys more findings that matter. Withholding information to make the test harder mostly makes it more expensive.
How Brexa approaches this
Brexa's Discover stage maps what an attacker can see from outside, and testing then continues with whatever access the scope allows. Continuous testing can run connected to the codebase, where the blue agent drafts fixes as reviewed pull requests, or reporting to a security or IT team. The services overview explains both options.
Frequently asked questions
Is gray box testing cheaper than black box testing?
Not necessarily per day, but it usually delivers more coverage for the same budget because less time goes to discovery. The cost difference depends on scope and the provider's pricing model.
Do we have to share source code for a penetration test?
No. Most application tests are gray box and do not need source code. Sharing code is useful for high-risk components, and should be covered by a confidentiality agreement and clear data handling rules.
Which approach do compliance auditors expect?
Standards generally care that the right scope was tested with an appropriate methodology, rather than naming black, gray or white box. Authenticated testing of in-scope applications is common because it gives more meaningful coverage.
Can one test combine approaches?
Yes, and many do. A common pattern is a black box review of the external perimeter followed by gray box testing of the main application with user accounts.
Sources
Written and reviewed by the Brexa team. Educational information, not legal or compliance advice. See our editorial policy.
Keep reading
Find out what an attacker could do with your systems.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.