Black-box, gray-box, and white-box penetration testing describe how much information and access testers receive before the assessment. The right choice depends on the question you need answered: what an unfamiliar outsider can discover, what an ordinary user can do, or whether a known design contains exploitable weaknesses.
Choose the approach by writing down the starting assumptions. A label alone does not tell you which systems, application roles, documents, or source code the engagement includes. This guide helps buyers decide what to provide and what conclusions to expect.
What is the difference between black-box, gray-box, and white-box testing?
The UK National Cyber Security Centre's penetration-testing guidance distinguishes assessments by the information supplied to testers. In practice, use the terms as a starting point for an explicit access agreement:
- Black-box: Testers receive little or no internal knowledge of the target. They discover relevant details while working within the authorized scope.
- Gray-box: Testers receive selected information or access, such as an ordinary user account, a description of roles, or limited architecture documentation.
- White-box: Testers receive extensive internal information. Depending on the engagement, this may include designs, configuration details, source code, and relevant credentials.
The OWASP Web Security Testing Guide also describes gray-box testing as using partial knowledge of an application. The names are not guarantees of coverage. A white-box proposal does not automatically include a complete source-code review, and a gray-box assessment does not automatically cover every account role. Spell out the supplied materials and planned testing.
Choose the approach that answers your question
| Your question | Approach to discuss | Scope detail that matters |
|---|---|---|
| What can an unfamiliar outsider discover and exploit? | Black-box | Known targets, discovery boundaries, and time allocated to reconnaissance. |
| Can a normal user cross an access boundary? | Gray-box | Representative roles, separate test users, and expected permissions. |
| Do weaknesses remain when the design is available for examination? | White-box | Which documents, code, configurations, and validation activities are included. |
These are planning examples, not universal rules. A provider may combine approaches in one engagement, but the report should identify where the assumptions change. For example, access supplied after an unsuccessful external phase must not be presented as access the tester gained.
Limited knowledge changes how testing time is spent
Discovery is part of a limited-information assessment. If your question is specifically about an outsider's opportunity, that effort may be central to the test. If your question is whether a known application enforces permissions, withholding the role model may spend the available time on information your team already has.
Ask the provider to explain that tradeoff in the proposal. Request a breakdown of the intended discovery, validation, and reporting work, together with how incomplete coverage will be described. Do not assume that a test with less supplied information is always more rigorous, or that extensive access guarantees every weakness will be found.
A hypothetical customer portal makes the choice concrete
Imagine a distributor with a portal used by customers and support staff. Leadership wants to know whether one customer can see another customer's order records. This is a hypothetical planning example, not a claim about a customer engagement.
For that question, selected customer accounts, synthetic records owned by different customers, and an explanation of expected permissions can make a gray-box scope useful. The assessment can focus on the boundary leadership actually needs validated. An unauthenticated check alone would leave the authenticated customer-to-customer question unanswered.
A different objective could justify a different starting point. If leadership wants evidence about what an unfamiliar outsider can reach without an account, define that phase separately. If developers need investigation informed by the implementation, agree on the materials and review activities instead of assuming that “white-box” promises them all.
Black-box is not the same as external testing
Internal and external describe the tester's starting position relative to the agreed network boundary. Black-box, gray-box, and white-box describe supplied knowledge and access. An external application assessment can use authorized accounts and documentation. An internal assessment can begin with limited privileges.
Use our internal vs. external penetration testing comparison to choose the network perspective. Then agree on what the tester will know and receive. Keep both decisions in the scope so the findings can be interpreted correctly.
Write the access agreement before testing begins
NIST SP 800-115 provides foundational guidance on planning security assessments and rules of engagement. Turn your chosen approach into practical arrangements:
- Information: List the documents, target inventory, role descriptions, and other materials to be supplied.
- Access: Define connection points, accounts, privileges, MFA arrangements, and how credentials will be transferred securely.
- Permissions: Record authorized activities, exclusions, third-party approvals, testing windows, and escalation contacts.
- Changes: Decide how additional access during testing will be approved and recorded.
- Reporting: Require a distinction between supplied access, access actually gained, untested areas, and demonstrated impact.
- Closeout: Assign ownership for account removal, access revocation, remediation, and any agreed retesting.
For application engagements, use our test account preparation checklist to build the permission matrix. When reviewing results, our penetration testing evidence guide helps separate observations from assumptions.
Network Box USA's penetration testing services help organizations define testing scope, evaluate weaknesses, and plan remediation. Contact our team with your objective, systems, and target date to discuss an appropriate approach and a private quote.