Black Box vs White Box Penetration Testing: Which to Buy
Black box vs white box penetration testing comes down to what you hand the tester: nothing but the target (black box), or full detail such as source code (white box). If your app has a login, ask for the middle option, gray box: a test account for each user role. Without accounts, the tester may never see behind the login.
Sources and published offers checked October 9, 2026. We read the pages; we did not buy or run a test.
Black box vs white box penetration testing: what each one tests
The three labels describe one thing: how much the tester knows and can access on day one. They do not describe how good the test is, who does it, or what it costs.
A penetration test (pentest) is an authorized attempt to break into a system to find weaknesses before someone else does. Gray box is also spelled grey box.
| Comparison point | Black box | Gray box | White box |
|---|---|---|---|
| What you hand over | The target address. Nothing else. | Test accounts for each user role. Often some documentation. | Internal detail: source code, architecture diagrams, configuration, and accounts where the scope needs them. |
| What gets tested | What a tester can find and reach from the agreed starting point without supplied internal knowledge. | What a logged-in user can do, plus any public testing named in the quote. That includes reaching data they should not see. | The running system and source or design work named in the quote, using internal detail to find flaws that are hard to spot from outside. |
| What can stay untested | Authenticated areas, unless the tester gains access or the scope supplies accounts. | Code-only flaws, plus any public or authenticated work the quote excludes. | Anything the quote excludes. Source access does not guarantee a full code review. |
| Fits when | The target has no login, or you want to see how far an outsider gets unaided. | Your app has users, roles or customer accounts. | The code itself is the worry: before a launch, after a breach, or around payment and permission logic. |
The definitions follow the NIST glossary, which describes black box testing as assuming "no knowledge of the internal structure and implementation detail," and white box testing as assuming "explicit and substantial knowledge" of it. The fit column is our judgment.
Think of a locksmith checking your building. From the street, they test the front door. With a tenant's key, they test whether that key opens other people's apartments. With the blueprints, they find the service hatch nobody remembered.
Which one do you need?
Start with what is being tested and what question the test must answer.
| Your situation | Ask for | Why |
|---|---|---|
| A web app or SaaS product with logins and roles | Gray box, with an account for each role | Most of what matters sits behind the login. |
| A public website or your internet-facing network, with no user accounts | Black box | There is no login to get behind. |
| "Can one customer see another customer's data?" | Gray box, with accounts in two separate test customers | Only a logged-in tester can try it. |
| A new product, a rewrite, or code that handles money or permissions | White box, with the code work written into the quote | The question is about the code. |
| "Would our team notice an attack?" | Black box, agreed in advance with a few people inside | You are testing the alarm as well as the lock. |
| A PCI DSS assessment | Usually gray or white box. Confirm with your assessor. | See the PCI guidance below. |
| Someone asked for "a pentest" and you are not sure | Ask them first | Their answer picks the level. |
You can mix them. Bureau Veritas, a testing firm, says a common combination is black box on the infrastructure and gray box on the application, and that gray box is the most common choice among its own clients (its definitions, checked October 9, 2026). That is one firm describing its own customers, not a market statistic.
Already have a provider or a recent test? Check what access that test had before buying another. If it covered the roles and data you care about, you may not need a new one.
What does it cost to test behind the login?
One provider publishes both prices, so you can see the gap. Pentest-Tools.com lists a black box web app test at a fixed $3,400, and a gray box test starting from $3,400 plus $900 per user role (its service page, checked October 9, 2026).
We ran its formula for a few role counts:
| What is tested | Published formula | Published amount | Stated timing |
|---|---|---|---|
| Black box: anonymous attacker only | Fixed price | $3,400 | 3 working days, best effort. Report on the 4th day. |
| Gray box, 1 user role | $3,400 + 1 × $900 | $4,300 | 4 or more working days. Report when ready. |
| Gray box, 2 user roles | $3,400 + 2 × $900 | $5,200 | Same |
| Gray box, 3 user roles | $3,400 + 3 × $900 | $6,100 | Same |
These are one provider's published amounts, not quotes and not a market average. The gray box formula is a "starting from" price. It does not tell you what an API, a complex app or a retest adds, and the page lists no retest terms. So the full price is still open until you have a written quote.
The point holds anyway. At this provider, the lower-priced black box offer covers an anonymous-attacker scenario rather than the three authenticated roles. If your app has three roles, the cheaper test does not commit to examining any of them.
Is black box or white box cheaper?
Neither label sets the price. The work does.
A black box test can cost less when the time is fixed and the tester simply sees less, as in the example above. It can cost more when you need the same coverage, because the tester spends paid days finding things you could have told them. PCI Security Standards Council guidance puts it this way: a black box assessment "may require more time, money, and resources" to meet PCI DSS needs (Penetration Testing Guidance v1.1, section 2, published September 2017).
White box adds work only if the provider does something with the internal detail you supply. So compare quotes on three things: the same targets and roles, the same work, and the full commitment. Our penetration testing cost page has published prices by scope, and the quote comparison page shows how to line proposals up.
Is black box testing more realistic?
It matches an outsider starting with little or no specific knowledge. It does not recreate every real attack, because a real attacker may spend much longer and is not bound by the test's limits.
A hired tester works within an agreed scope and testing window. In a black box test of a login-protected app, much of that window can go to getting in. If they don't get in, your report says little about the logged-in part of the app your customers use. The same PCI guidance says white box and gray box assessments "yield more accurate results" and give a fuller test than a pure black box one.
Giving access does not make the test fake. It changes the question from "can a stranger get in this week?" to "what can a user do once they are in?" If you need both answers, ask for two phases: an unaided attempt first, then accounts. Have the report say which findings came from which phase.
Can a black box pentest use login credentials?
Under the usual definitions, supplied accounts make it a gray box test. But providers do not use the labels consistently.
Cobalt's documentation, for example, describes black box as "no internal knowledge" and gray box as partial knowledge "such as valid user credentials." Its Autonomous Pentest is also described as a "black-box web/API pentester" that tests each supplied credential set (Cobalt methodologies, Autonomous Web Methodologies, checked October 9, 2026). The Pentest-Tools.com page above says its price depends on "black box or white box," and then lists black box and grey box offers.
So if a provider sold you a black box test and now asks for logins, that request does not by itself mean something is wrong. They may be trying to test more of your app, but the request can change the agreed access conditions or scope. Ask three things in writing: does the scope change, does the price change, and will the report say which findings needed the accounts?
Does white box include a full source code review?
Not automatically. Having the code and reviewing the code are different jobs.
Bureau Veritas says that in its white box tests (it calls them crystal box) the testers have the source code, but that it "normally will not perform a full source code review" during a penetration test. The code is mainly used to check security functions (same page, checked October 9, 2026).
Send this before you share anything: "Will you review our source code, or use it only to guide tests of the running app? Which repositories or modules are included, and how will the report show that work?"
If you would rather not share code, say so. Gray box does not need it. If you do share it, agree first on who can see it, where it is stored and when it is deleted.
Which published offers fit? A worked example
Say you run a 30-person SaaS company. You have one web app with three roles (owner, editor, viewer), and a customer wants a pentest report. Your developers will not share source code.
That gives two must-haves: all three roles tested, and no source code. We checked four published offers against them. This is our Purchase Check: one buyer's requirements held up against each offer's own published terms.
| Offer | Three roles tested | No source code needed | What follows |
|---|---|---|---|
| Pentest-Tools.com, black box | Mismatch. The scenario is an anonymous attacker. | Supported | Rule it out for this buyer. It could still fit a public site. |
| Pentest-Tools.com, gray box | Supported, at a starting amount of $6,100 ($3,400 + 3 × $900). | Supported | Worth a closer look. API, complexity and retest price are unresolved. |
| Cobalt, Autonomous Pentest | Mismatch. Its setup article lists "up to 2 roles under test." | Supported. It takes login details, not code. | Rule it out for three roles, or ask Cobalt about its human-led tests. |
| Intruder, AI web app pentest | Unresolved. Step two is "Provide context & credentials"; a role limit is not stated. | Mismatch. Step one is "Connect your codebase." | Rule it out unless your developers agree to share code. |
Sources, all provider-published and checked October 9, 2026: Pentest-Tools.com, Cobalt's Autonomous Pentest setup article, Intruder. "Supported" means that one condition matches the published terms. It is not a verdict on testing quality, and it does not mean your customer will accept the report. No provider has quoted for this example.
For this buyer, the gray box offer is the one to pursue, and the question to send is: "For one web app with three roles, what is the complete price, including the API and one retest?"
Change one fact and the answer moves. If the developers agree to share code, Intruder's source-code mismatch clears, but its three-role coverage is still unresolved. If the app has two roles, Cobalt's role mismatch clears, but its other published prerequisites still need to fit.
If one of these is already your pick, go straight to it:
How many test accounts should you set up?
Plan on two accounts for each role, in two separate test customers.
The reason is simple. A tester needs two users of the same kind to check whether one can reach the other's data. The OWASP Web Security Testing Guide says to create "two users with identical privileges" for each role when testing this (WSTG-ATHZ-02, checked October 9, 2026).
For the example company, that looks like this:
| User role | Test customer A | Test customer B |
|---|---|---|
| Owner | 1 account | 1 account |
| Editor | 1 account | 1 account |
| Viewer | 1 account | 1 account |
| Data | Made-up records | Different made-up records |
That is 3 roles × 2 test customers = 6 accounts. It lets the tester try both directions: can a viewer do what an owner can, and can customer A's editor open customer B's records? If users keep private items inside one customer, add a second editor to customer A.
This is a starting list for the example, not a rule. And note the price table above counts roles, not accounts. Ask whether extra accounts for the same role change the price.
What do auditors and customers expect?
Whoever reads the report decides what is acceptable. No label guarantees it.
For PCI DSS, the PCI Security Standards Council's 2017 guidance says PCI penetration tests are "typically performed as either white-box or grey-box assessments." It also says that when an application has logins, testing should cover all roles, and it strongly encourages giving the tester credentials (sections 2, 2.3.1 and 4.2.1). That document is guidance written for an earlier version of the standard. It does not replace the standard itself. Read the current PCI DSS penetration testing requirement in the PCI SSC document library with your assessor before you settle the scope.
For a SOC 2 audit, an ISO 27001 audit or a customer questionnaire, we are not citing a required level here. Ask the reader directly: "Which systems must the test cover, does it need to include logged-in testing, and what must the report show?" Our SOC 2 penetration testing page covers that audit in more detail.
What to put in your scope request
Send every provider the same request. Then their answers line up and you can compare them.
Fill in the brackets and copy it.
Subject: Access, coverage and price for our penetration test
Why we need it. We need this test to answer: [your question]. The report is for [customer, auditor or internal team]. We need it by [date].
Targets. [Applications, API addresses, domains or IP ranges, and the environment]. Out of scope: [items].
Access level. We are asking for [black box / gray box / white box]. We can provide: [number] test accounts covering these roles: [roles], in [number] separate test customers, with made-up data. We [can / cannot] share source code.
Coverage. Please list the roles, workflows and API functions your price covers. Tell us what is excluded and what happens to coverage if an account does not work.
Code. If source code is included, say whether you will review it or only use it to guide testing, and which repositories are covered.
Who does the work. Tell us how much is done by people, how much is automated, and who reviews the findings.
Report and retest. Confirm the report will state the access you had, what you tested and what you did not. State how many retests are included, the deadline to request one, and any fee.
Price and dates. Give the complete price, anything that could change it, the test start date and the report date.
Please do not ask for passwords or code by email. We will agree a secure way to share them. This request is not permission to test. Testing starts only after we both sign a written authorization that names the targets and the rules.
You now know which access level to ask for and what the quote has to say. If you still need to choose providers, Find My PenTest Match asks a few quick questions, shows which of our compared offers fit, and gives you a brief to send to the providers you pick. It is free, needs no email or sign-up, and sends nothing to providers.
For a filled-in example of the whole document, see our penetration testing scope page.
Quick answers
Can an internal penetration test be black box?
Yes. "Internal" says where the tester starts: inside your network. "Black box" says what they know. Bureau Veritas describes an internal black box test as plugging in and seeing how far the tester can get.
Does a clean black box report mean the app is secure?
No. It means nothing was found in what the tester could reach. Read the scope section of the report. If the tester had no accounts, the pages behind your login were likely not tested.
Is a black box pentest the same as a vulnerability scan?
No. A vulnerability scan identifies and reports potential weaknesses, typically with automated tools and manual verification. A black box pentest actively investigates whether weaknesses can be exploited, starting without inside knowledge. See penetration testing vs vulnerability scanning.
Is this the same as black box and white box software testing?
The words are borrowed from software quality testing, where developers test their own code. This page is about security tests you buy from an outside provider. A developer's unit tests are not a white box penetration test.
Sources
All checked October 9, 2026. Provider facts are what each provider's own page says. How we check offers.
- NIST glossary: black box testing and white box testing
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment, September 2008, sections 2.3 and 5.2.2
- PCI Security Standards Council: Penetration Testing Guidance v1.1, September 2017, sections 1.3, 2, 2.3.1 and 4.2.1. Supplemental guidance, not the text of the current standard.
- OWASP Web Security Testing Guide v4.2: WSTG-ATHZ-02
- Pentest-Tools.com: web application penetration testing. The page states it was updated August 19, 2026.
- Cobalt: methodologies, Autonomous Pentest setup and Autonomous Web Methodologies
- Intruder: AI pentests
- Bureau Veritas Cybersecurity: black, gray and crystal boxes
None of these organizations endorses this page. The PenTest Index does not perform, authorize or certify penetration testing.