On this page
- Two ways to classify penetration testing
- Black box penetration testing
- Grey box penetration testing
- White box penetration testing
- Black box vs grey box vs white box compared
- Other testing dimensions you will see in a proposal
- Penetration testing by target
- Which approach for which target: a quick matrix
- How to choose the right type of penetration test
- What each approach needs from you
- How the approach affects cost and time
- Common misconceptions
- How Summit approaches it
- Frequently asked questions
Two ways to classify penetration testing
People often mix two separate questions when they talk about the types of penetration testing:
- How much the tester knows
- Black box, grey box or white box. This decides depth, efficiency and how realistic the starting point is.
- What the tester attacks
- Web application, API, mobile app, external or internal network, cloud, thick client, wireless, IoT, people (social engineering) or the whole organisation (red team).
Every engagement has an answer to both. A “grey box API penetration test” and a “black box external network test” are both precise descriptions. When you scope a test, or read a provider’s quote, check that both are stated. If they are not, you cannot compare quotes or judge what the report proves.
There are also a few other dimensions you will see in proposals: authenticated or unauthenticated, internal or external, announced or unannounced, and manual or automated. We cover each below. If you are new to the subject, start with our guide to what a VAPT assessment is.
Black box penetration testing
In a black box test the tester starts with almost nothing: a domain name, an IP range or an app store link. There are no credentials, no documentation and no source code. The tester behaves like an anonymous attacker on the internet and has to discover everything for themselves.
What it is good at
- Showing what an outsider can see and reach: exposed services, forgotten subdomains, login pages, leaked information
- Testing the perimeter, including firewalls, VPN gateways, email security and public-facing applications
- Checking how much your public footprint reveals, which is the first step of any real attack
- Producing a realistic picture of opportunistic, untargeted attacks
Where it falls short
A large share of the testing budget goes on reconnaissance and guessing. Anything behind a login, such as the dashboards, APIs and data your customers actually use, is largely invisible unless the tester can register an account or break in first. That means black box tests often miss the most serious class of issues in modern applications: broken access control, such as one customer reading another’s records. Our IDOR case study is a real example of a flaw only visible after logging in.
Use it when you want an external attack surface review, the target is internet-facing infrastructure, or you want to test detection without giving the testers any help.
Grey box penetration testing
In a grey box (or gray box) test the tester gets partial knowledge, typically:
- Test accounts for each user role, for example customer, manager and administrator, ideally in two separate tenants
- An API specification such as an OpenAPI or Postman collection
- A short walkthrough of key workflows, such as checkout, approvals or payments
- For networks, a list of in-scope ranges and perhaps a standard domain user account
This mirrors the most damaging real-world attackers: a malicious customer, a compromised user account, or an insider with ordinary access. The tester skips the guesswork and spends the time where risk concentrates, inside the application.
What it is good at
Grey box testing is the most efficient way to find access-control flaws, privilege escalation, business logic abuse, multi-tenant data leaks and insecure API endpoints. Because every role is tested, the tester can check that a user in one role or tenant cannot do what only another should. These are exactly the issues listed at the top of the OWASP API Security Top 10 and are the most common serious findings in our reports.
Where it falls short
It does not show how an outsider gets their first foothold, and it relies on you providing accurate accounts and documentation.
Use it when you are testing a web application, API or mobile app, need evidence for SOC 2, ISO 27001 or a customer security review, or want the best coverage in a fixed number of days. For most of our web application VAPT and API security testing engagements, grey box is the default.
White box penetration testing
In a white box test (also called clear box, glass box or crystal box testing) the tester has full knowledge: source code, architecture diagrams, infrastructure-as-code, configuration files and often direct conversations with developers.
What it is good at
- Finding issues that are hard to reach from outside, such as weak cryptography, hidden debug endpoints, hard-coded secrets and unsafe deserialisation
- Tracing a suspicious behaviour back to the exact line of code, which makes remediation faster
- Covering far more of the code base in the same time, including rarely used features
- Reviewing cloud and Kubernetes configuration directly rather than inferring it
Where it falls short
It takes more preparation and more trust: you share code and design documents with the testing team under NDA. It is also less realistic as a simulation of an outside attacker. And code review alone misses issues that only appear in the running system, such as misconfigured servers, so the best white box engagements combine source code review with live testing.
Use it when the system is high-risk (payments, health data, authentication services), you are preparing for a major release or an acquisition, or earlier black and grey box tests have plateaued.
Black box vs grey box vs white box compared
| Black box | Grey box | White box | |
|---|---|---|---|
| Tester starts with | A URL, IP range or app | Accounts per role, API specs | Code, architecture, configuration |
| Simulates | Anonymous outside attacker | Malicious user or compromised account | Insider with full knowledge |
| Best at finding | Exposed services, perimeter weaknesses | Access control, logic flaws, tenant leaks | Deep code flaws, secrets, crypto, config |
| Coverage per day | Lowest | High | Highest |
| Preparation needed | Minimal | Moderate | Most |
| Typical use | External network, attack surface review | Web, API and mobile apps | High-risk apps, pre-release, M&A |
The approach is a dial, not a switch
Many engagements mix approaches. A common pattern is a short black box phase against the login and registration flows, followed by grey box testing of everything behind the login, with code review of the authentication module. Ask your provider to state which parts of the scope use which approach.
Other testing dimensions you will see in a proposal
Authenticated vs unauthenticated
Whether the tester logs in. For applications, authenticated testing is what makes a test grey box, and it is where most high-severity findings appear.
External vs internal
External tests start from the internet. Internal tests start inside your network, simulating a compromised laptop or a malicious insider.
Announced vs unannounced
In announced tests your security team knows the timing. Unannounced (double-blind) tests also measure whether your monitoring and response notice the attack.
Assumed breach
The tester starts with a foothold, such as a standard employee laptop, to focus time on what happens after initial access.
Manual vs automated
Scanners find known patterns quickly. Manual testing finds logic flaws and chains issues together. A credible penetration test is mostly manual, with scanning as support.
Point-in-time vs continuous
A traditional test covers a fixed window. Continuous testing or regular retests track a product that changes every week.
Penetration testing by target
The second way to classify penetration testing is by what is being tested. The right knowledge level differs by target.
Web application penetration testing
Tests the application in the browser and the server behind it: authentication, session management, access control, input handling, business logic, file uploads and integrations. The reference methodology is the OWASP Web Security Testing Guide.
Recommended approach: grey box, with an account for every role and two tenants for multi-tenant SaaS. A black box test of a web application mostly tests the login page. See our web application VAPT.
API penetration testing
Tests REST, GraphQL, gRPC and SOAP endpoints directly, rather than through the front end. APIs often expose more than the user interface shows, including fields and operations the app never calls. Broken object-level authorisation is the top issue in the OWASP API Security Top 10.
Recommended approach: grey box with an API specification and tokens for each role. Without a specification, the tester spends time rebuilding it from traffic. See API security testing, and our guide to fixing a CORS misconfiguration, one of the most common API findings.
Mobile application penetration testing
Tests iOS and Android apps on the device (local storage, certificate pinning, use of the keychain or keystore, inter-app communication) and the APIs they call. The reference is the OWASP MASVS and MASTG.
Recommended approach: grey box with test accounts and builds you provide. Static analysis of the app binary is effectively white box for the client side even without source code. See mobile app VAPT.
Network penetration testing
External network tests target internet-facing IP addresses and services: VPN gateways, mail servers, remote access and exposed management interfaces. Internal tests start inside the network and look at Active Directory, file shares, legacy protocols, patching and lateral movement.
Recommended approach: black box for external testing, with only your IP ranges and domains; grey box or assumed breach for internal testing, starting from a standard user account. PCI DSS requires both internal and external penetration testing at least once every 12 months and after significant changes. See network VAPT.
Cloud security testing
Reviews AWS, Azure and GCP accounts for identity and access management weaknesses, public storage, exposed services, logging gaps and network paths between environments, usually against the CIS Benchmarks.
Recommended approach: white box, with read-only access to the cloud accounts, combined with external testing of what is exposed. Cloud configuration is far more efficiently reviewed from inside than guessed from outside. See cloud security assessment.
Thick client penetration testing
Tests desktop applications installed on users’ machines, their local files and memory, and the servers and databases they talk to. Common findings include hard-coded credentials, direct database connections and client-side security checks that can be bypassed.
Recommended approach: grey box with installers and test accounts. See thick client VAPT.
Source code review
Not a penetration test in itself, but the white box partner to one: a manual review of authentication, authorisation, input handling, cryptography and secrets, supported by static analysis tools.
Recommended approach: white box by definition. It is most valuable alongside a grey box test of the running application. See source code review.
Wireless, IoT and hardware testing
Wireless tests check Wi-Fi encryption, guest network isolation and rogue access points, and usually need a tester on site. IoT and hardware testing covers firmware, debug interfaces, radio protocols and the cloud services devices connect to.
Recommended approach: grey or white box, with devices, firmware and documentation supplied, because black box hardware testing is slow and expensive.
Social engineering and phishing
Tests people and processes: phishing emails, phone pretexting and sometimes physical entry. The aim is to measure behaviour and the effectiveness of reporting and controls, not to blame individuals.
Recommended approach: black box from the employees’ point of view, with full agreement from leadership and HR. See phishing simulations.
Red team operations
A red team combines all of the above to pursue a goal, such as reaching customer data, while testing whether your security team detects and responds. Unlike a penetration test, the aim is not to list every weakness but to show whether an attack would succeed and be noticed.
Recommended approach: usually black box and unannounced to the defenders, often with an assumed-breach phase. See red team operations, and our comparison of red teaming companies in India.
Which approach for which target: a quick matrix
| Target | Black box | Grey box | White box |
|---|---|---|---|
| Web application | Login and public pages only | Recommended | Add for high-risk apps |
| API | Limited value | Recommended | Add with code review |
| Mobile app | Limited value | Recommended | Binary analysis adds depth |
| External network | Recommended | Optional | Rarely needed |
| Internal network | Possible | Recommended (assumed breach) | Optional |
| Cloud | External exposure only | Possible | Recommended |
| Thick client | Limited value | Recommended | Add with code review |
| Social engineering | Recommended | Not applicable | Not applicable |
| Red team | Recommended | Assumed-breach phase | Not typical |
How to choose the right type of penetration test
Start with the question you need answered, not the label.
- “Could an anonymous attacker get in?” Choose a black box external test of your internet-facing estate.
- “Can one customer see another customer’s data?” Choose a grey box application and API test with multiple roles and tenants. This is the question most SaaS buyers and auditors care about.
- “Is this critical system secure all the way down?” Choose white box testing: code review plus live testing with architecture knowledge.
- “If someone gets in, how far can they go, and would we notice?” Choose an internal assumed-breach test or a red team operation.
- “What do our auditors or customers expect?” Usually a grey box test of the in-scope applications plus external and, where relevant, internal network testing, with a retest. Our guides to the SOC 2 VAPT report and ISO 27001 VAPT explain what each expects.
What each approach needs from you
Black box
Written authorisation, the list of in-scope domains and IP ranges, testing windows and an emergency contact. Nothing else, by design.
Grey box
Everything for black box, plus accounts for every role (and two tenants for SaaS), API specifications, a staging or production decision and a short workflow walkthrough.
White box
Everything for grey box, plus read access to the relevant repositories, architecture diagrams, infrastructure-as-code and a developer contact for questions.
Whatever the approach, prepare test data you are comfortable with the testers seeing, make sure backups and monitoring are in place, and agree in advance which actions are off limits, such as denial-of-service testing or mass emails.
How the approach affects cost and time
Testing is usually priced by effort, so the approach changes what you get for the same budget:
- Black box spends a large share of effort on discovery, so the same number of days covers less of the application.
- Grey box puts almost all of the effort into testing functionality, which is why it usually gives the most findings per day for applications.
- White box may add days for code review, but it finds issues faster and shortens remediation, because developers get the exact location of each flaw.
A useful comparison when reviewing quotes: ask each provider how many tester-days are included, which approach applies to which part of the scope, and whether a retest is included.
Common misconceptions
"Black box is the most realistic, so it is the best."
Real attackers have unlimited time and often valid credentials from phishing or leaks. A time-boxed black box test is less realistic than it sounds, and misses what is behind the login.
"White box is cheating."
Giving testers more information is not cheating; it lets them find more of what a determined attacker would eventually find.
"A scan is a black box test."
Automated scanning is unauthenticated pattern matching. A black box penetration test still involves a skilled human chaining findings together.
"We passed a black box test, so we are secure."
It shows what an outsider found in the time available. It says little about what any logged-in user can do.
How Summit approaches it
For applications and APIs we default to grey box testing with every role and, for SaaS, two tenants, because that is where the issues that leak customer data are found. We add white box review for high-risk components, black box testing for your external attack surface, and assumed-breach or red team work once the foundations are in place. Every scope document states the approach for each target, so you know exactly what the report proves.
Not sure which type of test you need?
Tell us what you need tested and who is asking for the report. We will recommend the approach, explain the trade-offs and send a fixed scope and quote. Get a quote or see a sample VAPT report.
Frequently asked questions
What are the three types of penetration testing?
By the tester's level of knowledge, penetration tests are black box (no credentials or internal information), grey box (test accounts and some documentation) and white box (full access to source code, architecture and configuration). Tests are also grouped by target, such as web application, API, mobile, network, cloud, thick client, social engineering and red team testing.
What is the difference between black box and white box testing?
In black box testing the tester starts with nothing but the target's address, like an outside attacker, so the test shows what is exposed to the internet but spends time on discovery. In white box testing the tester has source code, architecture and configuration, so they can trace weaknesses directly and cover far more of the system in the same time.
Which type of penetration testing is best?
For most applications, grey box testing gives the best value: the tester gets accounts for each user role, so they can test access control and business logic, which is where the most serious issues usually are. Add white box elements such as code review for high-risk systems, and use black box testing when the question is specifically what an anonymous outsider can reach.
Is grey box testing the same as authenticated testing?
Mostly. Authenticated testing means the tester logs in with valid accounts, which is the defining feature of a grey box web, API or mobile test. Grey box can also include partial documentation such as API specifications or network diagrams.
Do SOC 2, ISO 27001 or PCI DSS require a particular type of penetration test?
None of them mandates black, grey or white box by name. PCI DSS requires internal and external penetration testing at least every 12 months and after significant changes. SOC 2 auditors and ISO 27001 certification bodies look for a risk-based, independent test with a clear scope, and in practice expect authenticated testing of the applications in scope.
Does white box testing replace a penetration test?
No. White box access makes a penetration test more thorough, but source code review alone cannot show how the deployed system, its configuration and its infrastructure behave together. The strongest approach combines code review with live testing of the running application.
