Gray box testing is a test method where the tester has some knowledge of the system's internal structure and implementation, but not all of it. NIST's glossary also calls it focused testing. In practice that means a login, an architecture diagram or API docs, so the tester spends time on flaws instead of discovery.
How is gray box different from black box and white box?
Think of a dial for how much the tester knows.
Black box gives the tester nothing beyond what an outsider has: a URL, a company name, an IP range. It resembles an external attacker with no insider help. Much of the time goes to mapping the target.
White box gives the tester full knowledge: source code, design documents, configuration. It finds the most per hour of effort and is the closest to a code audit.
Gray box sits between. NIST's glossary describes it as a methodology that assumes some knowledge of the internal structure and implementation detail of the assessment object. The tester might get two user accounts, a list of endpoints and a data flow diagram, but no repository access.
The labels describe knowledge, not skill. A strong tester does good work in any mode.
What does the tester typically receive?
There is no standard bundle, so agree it in writing. Common inputs include:
- Accounts at several privilege levels, for example a normal user, a manager and an administrator.
- API specifications or a list of routes.
- A diagram of components and where sensitive data flows.
- The technology stack, so the tester picks the right checks.
- A test tenant with seeded data they cannot damage production with.
Why does gray box find different bugs?
Authenticated testing exposes the part of an application most attackers eventually reach, because accounts are cheap to get. With two accounts the tester can check whether user A can read user B's records by changing an identifier. That class of authorization flaw is hard to find without being logged in, and tedious to find when you have to guess how the system is organized.
A constructed example: a SaaS invoicing app is tested with two ordinary customer accounts and an API list. The tester notices an endpoint that returns an invoice by number. Account A requests an invoice number belonging to account B and receives it. A black box test with no accounts would likely never reach that endpoint. A white box review would find it, at higher cost. Gray box reached it in the first afternoon.
When should you pick it?
Pick gray box when the question is "what can a user or partner who already has some access do?" It fits web apps with roles, multi-tenant products, mobile backends and internal tools. Pick black box when you want to measure external exposure and detection by your own team. Pick white box when you are about to ship something critical, or the cost of a miss is high.
Many teams run all three at different points: white box and code scanning during development, gray box before release, black box on a yearly rhythm.
How to check or apply this
- Write the question the test must answer, in one sentence, before choosing the mode.
- List what the tester gets and what stays hidden, and why.
- Provision accounts for each role and a separate test environment.
- Set rules of engagement: dates, targets, forbidden actions, who to call if something breaks.
- Ask for findings with reproduction steps and the account used, so engineers can retest.
- Fix and retest. Add the cases to automated tests so the bug does not return.
Quick check
Is gray box testing cheaper than white box testing?
Usually it needs less preparation because no code access or review is required, but cost depends on scope. It trades some depth for faster setup.
Does gray box testing require source code?
No. It assumes some knowledge of internals, which can be documents, accounts and diagrams. Source access moves you toward white box.
Sources
- NIST CSRC Glossary: gray box testing, fetched 18 October 2026.
- NIST CSRC Glossary: black box testing and white box testing.
Last reviewed: 18 October 2026.
