Black box, grey box and white box are the three answers to one scoping question: how much do the penetration testers know, and what access do they hold, when testing starts? The answer changes what a test can find, how long the testers spend on discovery instead of the parts of the application that hold customer data, and what the report can tell an auditor or an enterprise customer.
Quick answer: Black box penetration testing gives the testers nothing but the target's address, so it measures what an anonymous outsider can reach. Grey box penetration testing adds test accounts for every user role and documentation such as an API specification, so the testers reach the authenticated application, where most serious web application findings sit. White box penetration testing adds source code, architecture and configuration. For SOC 2 evidence, PCI DSS and enterprise security reviews, buy grey box; add white box where the risk lives in code, and keep black box for perimeter and red team questions.
The three terms are not vendor jargon. The PCI Security Standards Council defines them in its Penetration Testing Guidance by how much the tester knows about "the internal structure/design/implementation" of the target: none (black box), partial (grey box) or full (white box). The OWASP Web Security Testing Guide uses the same split, calling penetration testing without knowledge of the target's inner workings "commonly known as black-box testing" and describing the middle option as testing where the tester has "some partial knowledge" of the application.
Black box, grey box and white box at a glance
Black box | Grey box | White box | |
|---|---|---|---|
What the testers get | The target's address (URL, domain or IP range) and written authorization | Test accounts for each role, plus documentation such as an OpenAPI specification or architecture overview | Everything in grey box, plus source code, architecture diagrams and configuration |
What it simulates | An anonymous attacker on the internet | A customer, employee or partner with a login, or an attacker who has stolen one | An insider or an attacker who has read the code |
Where testing time goes | Discovery: mapping the surface and trying to get past the login | Authorization and business logic across roles and tenants | Tracing each finding to the code and policy that enforce it, and checking paths the running app rarely exposes |
Finds well | Exposed services and admin panels, forgotten subdomains and API versions, login, registration and password reset flaws, perimeter patch gaps | Broken access control, IDOR, privilege escalation between roles, cross-tenant access, session handling after login | Missing checks deep in code paths, hard-coded secrets, weak cryptography, hidden or dead routes, the root cause of logic flaws |
Misses | Most of what sits behind the login | Code-level causes and paths the user interface never calls | Little within scope, but it costs reading time and needs code access |
Best fit | External perimeter tests, red team opening moves | SOC 2, PCI DSS, enterprise security reviews, most web, API and mobile tests | Payment and billing logic, complex permission models, multi-tenant platforms, pre-launch releases |
Three one-line definitions an answer can be built from:
Black box penetration testing is a test in which the testers start with no credentials, documentation or source code, only the target's public address, and work as an outside attacker would.
Grey box penetration testing is a test in which the testers receive partial knowledge: test accounts for each user role, and usually API documentation or an architecture overview, but not the source code.
White box penetration testing is a test in which the testers receive full knowledge of the target, including source code, architecture and configuration, and use it while attacking the running system.
Black box: what it simulates and what it misses
A black box test answers one question honestly: what can a stranger with an internet connection reach? The testers enumerate the surface themselves, from DNS records and certificate logs to exposed ports, forgotten staging hosts, old API versions and admin interfaces that were never meant to be public. Then they attack what they find, including the parts of the application that work without an account: login, registration, password reset, account lockout and enumeration.
That is a real question, and for an external network perimeter it is the right one. It is also the opening move of a red team engagement, where the point is to see whether an attacker with no inside knowledge can get in and whether the defenders notice.
For a web application, black box has a structural limit. Everything behind the login is out of reach unless the testers can create an account, and self-registration usually yields one low-privilege user in one tenant. That is enough to look around, but not enough to test whether one customer can read another customer's data, whether a viewer can perform an admin action, or whether a support role leaks across tenants. Those questions need two accounts at minimum, in different roles and different tenants.
Time is the other limit. On a fixed budget, every hour spent mapping what the client could have described in a one-page document is an hour not spent on authorization. The PCI Security Standards Council says so directly: a black box assessment, where the entity provides no details of the target systems, "may require more time, money, and resources for the deliverables to meet the requirements of PCI DSS" (PCI SSC Penetration Testing Guidance, section 2).
Stingrai's web application and API testing starts black box for exactly this reason, then moves to grey box. The black box phase finds what an anonymous caller can enumerate and call, including endpoints and versions the documentation never listed. The grey box phase then spends the rest of the engagement on the authenticated application.
Grey box: why most compliance and enterprise tests use it
Grey box is the default for most commercial web applications because that is where the serious findings are. Stingrai's State of Penetration Testing 2026, built from 1,206 verified findings across 55 penetration tests between October 2024 and August 2026, segments the findings by test type. In the 768 findings from 40 web application tests, the largest class was authentication and session at 28.1%, and broken access control (9.9%) and IDOR (7.9%) were also among the six largest classes.
Together those three identity and access classes are about 46% of web application findings, and the same report found that 70% of the 40 web application tests that produced findings surfaced at least one High or Critical authentication or authorization finding.
The dataset does not label engagements by box type, so it cannot say how many of those findings a black box test would have missed. What it shows is where the serious web findings live. Part of the authentication and session class (login, password reset, enumeration) is reachable from outside. Session handling after login, token scope and role changes are not. Broken access control and IDOR cannot be tested at all without accounts, because there is nothing to cross between: the test is whether user A can read or change user B's object, or whether a lower role can call a higher role's function.
OWASP is specific about the setup. Its test for insecure direct object references, WSTG-ATHZ-04, says "the best way to test for direct object references would be by having at least two (often more) users" (OWASP WSTG v4.2). Two users in the same role expose horizontal flaws; users in different roles expose vertical ones.
The PCI guidance asks for the same thing in compliance language. Where an application requires authentication, "testing should be performed against all roles or types of access," and for multi-tenant applications the customer should give the tester credentials with the same permissions as a customer user, to check whether they reach data beyond that customer's own (PCI SSC Penetration Testing Guidance, section 2.3.1).
Enterprise security reviews push the same way. One of the first questions a customer's security team asks of a vendor's report is whether another customer could reach their data, and only a test with accounts in more than one tenant can answer it. A report that lists the roles and tenants tested answers it on the page.
White box: source code, architecture and when it pays off
White box testing gives the testers the code and the design, and they use both while attacking the running application. It is not the same as a source code review on its own: the testers still exploit the live system and prove impact. The code tells them where to look and why a control fails.
The OWASP Testing Guide lists what source code review is particularly good at: "concurrency problems," "flawed business logic, access control problems, and cryptographic weaknesses," as well as "backdoors, Trojans, Easter eggs" (OWASP WSTG v4.2, Introduction). Those are the issues that dynamic testing reaches slowly or not at all: a missing authorization check on a route the interface never calls, a race condition in a refund flow, a feature flag that exposes an unfinished endpoint, a secret committed to the repository, a homemade token format.
White box also changes the remediation conversation. A finding that names the handler, middleware or policy file to change is fixed faster than one that only describes a request and response.
It pays off when the risk lives in code:
Payment, billing and refund logic, where a single missing check moves money.
Complex permission models, with many roles, delegated access or per-object sharing.
Multi-tenant platforms, where tenant isolation is enforced in application code rather than by separate infrastructure.
Custom authentication and cryptography, including token formats, SSO integrations and key handling.
Pre-launch releases and major rewrites, where the code exists before the traffic does and fixes are cheapest.
White box costs more reading time, and large codebases need a focus: name the services, modules or flows that matter, and the commit the test covers, so the report pins to a version.
Which box for which goal
Goal | Box type to buy | Why | What to hand over |
|---|---|---|---|
SOC 2 Type 2 evidence | Grey box, starting black box | SOC 2 does not prescribe a box type; customers reading the report want every customer-facing role tested | Test accounts per role, API specification, scope and dates inside the observation period |
PCI DSS (Requirement 11.4) | Grey box or white box | PCI SSC guidance: PCI DSS tests are "typically performed as either white-box or grey-box assessments"; all roles tested | Accounts for every role, including roles without cardholder data access; network and data flow diagrams |
Enterprise customer security review | Grey box with two tenants | Cross-tenant access is among the reviewer's first questions | Two users per role in two tenants, admin and support roles |
Pre-launch or major rewrite | White box | Code exists before traffic; fixes are cheapest before release | Read-only repository access, architecture diagram, the commit to test |
Payment, billing or permission-heavy features | White box | Logic and access control flaws are clearest in code | Code for the flows in scope, plus grey box accounts |
External network perimeter | Black box | The question is what the internet can reach | IP ranges and domains, written authorization |
Internal network | Grey box from an assumed-breach account | Starts where a phished employee would | A standard domain user account and network access |
Red team opening move | Black box full chain or assumed breach | Tests detection and response, not only vulnerabilities | Objectives, a small control group, rules of engagement |
Two notes on the table. SOC 2 does not require a penetration test at all, let alone a box type; the Trust Services Criteria name penetration testing only as an example of a separate evaluation, so the scope you write into your control description is what the auditor tests against. Our SOC 2 penetration testing guide covers that sentence in detail. And PCI DSS v4.0.1 carries the testing obligation in Requirement 11.4; the PCI SSC's guidance on box types was written for the earlier numbering (Requirement 11.3) but its definitions and its advice on roles still describe how assessors read a test. The PCI DSS penetration testing guide maps the current requirements.
How the box type changes duration and cost
The box type moves effort around more than it adds or removes it. What drives effort differs by type:
Box type | What drives effort | What happens on a fixed budget |
|---|---|---|
Black box | Size of the unknown surface; how hard the login is to get past | Discovery eats hours that would otherwise go to authorization testing |
Grey box | Number of roles, tenants and API endpoints or dynamic pages | Hours go to the role and tenant matrix, where the serious web findings are |
White box | Size of the codebase in scope, languages and frameworks | Reading time is added, but the testers stop guessing at controls they can read |
This is why quotes are built on counts. Stingrai's quote form asks how many web applications are in scope and roughly how many dynamic pages and API endpoints each contains, because that, more than the box type, sets the effort for a grey box web test.
On Stingrai's published plans the box type does not change the price. The Autonomous Pentest, Snipe alone, is US$3,000 one-time or US$650 per month on a 12-month plan, and lists black, white or grey box testing, up to 200 API endpoints or dynamic pages and up to 3 user roles for authenticated testing. The Hybrid Pentest, Snipe and Stingrai's penetration testers working together, is US$6,800 one-time or US$1,275 per month on a 12-month plan and includes everything in the Autonomous Pentest. Both cover "One web application and associated APIs." The Hybrid Pentest also comes with the attestation letter used as audit evidence for SOC 2, HIPAA and PCI DSS programs.
What to hand the testers
The handover decides whether a grey box or white box test delivers what it promised. A checklist by box type:
Every test
Written authorization from someone who can grant it for each asset, plus the scope by identifier: URLs, domains, IP ranges, API specifications, repositories.
Test windows, contacts for an emergency stop, and whether testing runs in production, staging or both.
Grey box, added
Two users per role. Two in the same role expose horizontal flaws; users in different roles expose vertical ones.
Two tenants for any multi-tenant product, with users in each.
Every privilege boundary: admin, support and service accounts, plus API keys or tokens for each scope the API issues.
Documentation: an OpenAPI or GraphQL schema, a Postman collection, or a short walkthrough of the main workflows.
MFA that testers can use, such as authenticator seeds for the test accounts, and seeded test data so state-changing tests do not touch real customers.
White box, added
Read-only access to the repository, or a snapshot, and the commit or tag to test.
An architecture diagram, where authentication and authorization are enforced (middleware, gateway, policy files), and infrastructure-as-code or gateway configuration if it is in scope.
A named engineer for questions about the code.
Credentials travel through an encrypted portal or agreed channel, never plaintext email or chat. Our guide to scoping a penetration test covers authorization, environments and stop conditions decision by decision.
How AI-assisted testing fits
Snipe, Stingrai's autonomous AI agent for web applications and their APIs, covers both ends of the spectrum. It runs black box dynamic testing against the running application, and with repository access it performs white box code review, tracing data flows through the source. Given test accounts for each user role, it tests authenticated, so the authorization matrix (IDOR, broken access control, business logic across roles) is within the agent's own reach. With repository access it can also generate AutoFix pull requests and gate pull requests before merge.
The Hybrid Pentest pairs Snipe with Stingrai's penetration testers, who test alongside it throughout the engagement, direct its focus and chain what it surfaces. Snipe covers web applications, their APIs and AI and LLM applications. Network, Active Directory, cloud, mobile and red team engagements are human-led, and their box type is set at scoping in the same way: external network tests usually start black box from the internet, and internal tests usually start grey box from an assumed-breach account.
About Stingrai
Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified penetration testers, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
For box types specifically: every human-led web application engagement is run by two named penetration testers, starts black box and moves to grey box with test accounts for every role, and adds white box review where repository access is given. Findings are posted to the PTaaS portal with a working proof of concept as they are confirmed, retesting of remediated findings is included, and the team has published 18 CVEs. Engagements run as one-time annual tests or as continuous programs. See web application penetration testing, API penetration testing, network penetration testing and red teaming.
Frequently asked questions
What is black box penetration testing?
Black box penetration testing is a test in which the testers start with no credentials, documentation or source code, only the target's public address, and work as an outside attacker would. It shows what an anonymous person on the internet can reach and is the right choice for external perimeter tests and red team opening moves. For a web application it misses most of what sits behind the login, which is why Stingrai's web application tests start black box and then move to grey box.
What is the difference between black box, grey box and white box penetration testing?
The difference is how much the testers know and hold when testing starts. Black box testers get only the target's address, grey box testers get test accounts for each role and documentation such as an API specification, and white box testers also get source code, architecture and configuration. The PCI Security Standards Council defines the three the same way: no knowledge, partial knowledge and full knowledge of the target's internal structure, design and implementation.
Which is better, black box or white box penetration testing?
Neither is better in general; they answer different questions. Black box measures what an outsider can reach, while white box finds flaws in code paths, logic and access control that the running application rarely exposes. For most web applications grey box is the best value, with white box added for payment logic, complex permissions, multi-tenant isolation and pre-launch code.
Is gray box penetration testing the same as grey box?
Yes. It is the same method spelled two ways: the testers receive partial knowledge of the target, typically test accounts for every user role and API documentation, but not the source code. Publishers differ on the spelling, and the PCI Security Standards Council uses grey-box.
Does PCI DSS require a grey box or white box penetration test?
PCI DSS does not name a box type, but the PCI Security Standards Council's Penetration Testing Guidance says PCI DSS penetration tests are typically performed as white box or grey box assessments, because they give more accurate results than pure black box. The same guidance asks for testing against all roles where an application requires authentication, and for customer-level credentials on multi-tenant applications.
How many test accounts do penetration testers need?
At least two users per role, and users in two tenants for any multi-tenant product. OWASP's test for insecure direct object references, WSTG-ATHZ-04, says the best way to test is with at least two, often more, users. Two users in the same role expose horizontal access flaws, and users in different roles expose vertical ones.
Does SOC 2 require a specific type of penetration test?
No. SOC 2 does not require a penetration test or a box type; the Trust Services Criteria mention penetration testing only as an example of a separate evaluation. Most SOC 2 programs still commission one, and a grey box test of every customer-facing role is what customers and their security reviewers expect to read in the report.
Related reading: How to scope a penetration test, The State of Penetration Testing 2026, Best web application penetration testing services, API authorization test matrix, PCI DSS penetration testing, What is a penetration testing service.
