White Box Pentest Guide 2026: What It Finds and When to Use It

White box penetration testing is a pentest in which the security researcher gets access to the source code, the architecture documentation and the people on the team, in addition to test accounts. They read the code looking for attack paths and confirm every suspicion by exploiting the running application. It is the deepest of the three approaches: it surfaces flaws that would take weeks to find from the outside — or would never show up at all.

This guide completes our series on the three pentest approaches. You’ll see what white box finds that the others don’t (with vulnerable and fixed code), how it works in practice, when it’s worth it, when it isn’t, and what it costs.

What is a white box pentest, in one definition

A white box pentest is an attack simulation carried out by someone who knows the system from the inside — the code, the business rules, the infrastructure and the integrations. Instead of discovering the application by trial and error, as in black box testing, the researcher uses the code as a map: they find where security decisions are made (who can see what, how money moves, where data comes from) and test whether each one holds up against an attacker.

OWASP itself backs this approach. In ASVS 4.0.3 (the Application Security Verification Standard), level 1 is described as the only level that is fully testable without source code; levels 2 and 3 require access to documentation, source code, configuration and the people involved in development. The standard even recommends replacing purely external tests with source-code-led pentests.

White box vs grey box vs black box

The three approaches answer different questions:

The other two are covered in depth in Black box pentesting and Grey box pentesting.

What white box finds that the others miss

The examples below are recurring patterns in SaaS and fintech. In every case, outside testing might eventually reach the flaw — but it takes luck, many attempts, or the route being visible in the interface. Reading the code, it shows up at once, together with all its variants.

1. Endpoint without an authorization check (CWE-639)

The endpoint trusts the identifier in the URL and never checks whether the resource belongs to the requester — the well-known BOLA/IDOR. From the outside, finding it takes two accounts and guessing identifiers. In the code, the researcher sees every route that queries the database without filtering by tenant, including the ones no screen calls.

// Vulnerable: fetches the invoice by the URL id only
app.get("/api/invoices/:id", auth, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

// Fixed: the filter includes the authenticated user's tenant
app.get("/api/invoices/:id", auth, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: { id: req.params.id, tenantId: req.user.tenantId },
  });
  if (!invoice) return res.sendStatus(404);
  res.json(invoice);
});

Reference: CWE-639 — Authorization Bypass Through User-Controlled Key.

2. Secrets in the code and in Git history (CWE-798)

A payment API key, a database password, an email service token. Even after the team deletes it from the code, the secret stays in the repository history — and in every copy of it. External testing rarely gets there; code review does, and the fix includes rotating the key, not just deleting the line.

// Vulnerable: the key lives in the code and in Git history
const stripe = new Stripe("sk_live_XXXXXXXXXXXX");

// Fixed: secret in an environment variable or vault, with rotation
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

Reference: CWE-798 — Use of Hard-coded Credentials.

3. Predictable tokens (CWE-330)

Password reset links, invitations, email confirmations: if the token is generated with a function that isn’t cryptographically secure, it can be predicted. From the outside this is nearly invisible — the token looks random. In the code, it’s one line.

// Vulnerable: Math.random is not meant for secrets
const resetToken = Math.random().toString(36).slice(2);

// Fixed: cryptographic generator
import { randomBytes } from "node:crypto";
const resetToken = randomBytes(32).toString("hex");

Reference: CWE-330 — Use of Insufficiently Random Values.

4. Deserializing external data (CWE-502)

When an application rebuilds objects from outside data (cookies, queues, caches, uploads) using a format that can execute code, the result can be remote code execution on the server. The vulnerable spot is usually far from the UI — in an integration or a background worker — which is exactly what reading the code reveals. The fix is to use formats that don’t execute code (such as JSON), validate the content and sign whatever must come back intact. Reference: CWE-502 — Deserialization of Untrusted Data.

5. Forgotten routes and hidden logic

A debug endpoint left in production, a route from an old API version, a feature flag that unlocks admin functions, an internal job that accepts external calls. None of this shows up in the interface — so it slips past black box and often grey box testing. With the code, the researcher lists every registered route and tests each one.

6. Vulnerable dependencies that are actually used

Dependency scanners list dozens of libraries with CVEs. What matters is whether the vulnerable code path is called by your code, with data an attacker controls. A white box review answers that — and turns a long list into a few items that truly need action.

How it works in practice

1. Scope and access. Agree on what’s in scope (repositories, modules, test environment, accounts) and a fixed version of the code, so findings point to stable files and lines.
2. Architecture and critical flows. Authentication, authorization, money movement, personal data and third-party integrations — that’s where risk concentrates.
3. Risk-driven review. It isn’t reading every line of the system: it’s following the paths an attacker would use, from external inputs to security decisions.
4. Validation against the running app. Every suspicion becomes a real test. Only findings with proof of exploitation (or a clear technical rationale) make it into the report.
5. Report and retest. Each finding with file and line, impact, steps to reproduce and a suggested fix; after the fixes, a retest.

Why it isn’t just running a SAST tool

Static analysis tools (SAST) are useful day to day, inside the CI pipeline. But they flag patterns, not attacks: they produce false positives, don’t understand business rules (“free-plan users can’t export reports”) and can’t tell whether a code path is reachable by an attacker. In a white box pentest, tools support the work — the researcher decides what is a flaw, and proves it. The OWASP Code Review Guide is a good reference on combining manual review with tooling.

When to choose white box

1. Fintech and payments

Money flows leave little room for error. For organizations that handle card data, PCI DSS v4.0 (requirement 6.2.3) requires bespoke and custom software to be reviewed before release to find and fix coding vulnerabilities. The official text is in the PCI SSC document library. For the Brazilian regulatory context, see fintech penetration testing and payments penetration testing.

2. New or rewritten critical modules

Authentication, permissions, billing, wallets, instant payments, rules engines: when one of these is built or heavily changed, reviewing the code before launch costs far less than finding the flaw in production.

3. Due diligence, enterprise customers or audits

Investors, acquirers and large customers increasingly ask for evidence of security testing. A white box report with a clear scope and methodology is strong evidence — without promising a certification, which depends on the auditor and the framework.

4. After an incident

Fixing the exploited spot isn’t enough: the same flaw usually exists elsewhere in the code. A white box review finds the variants and the root cause.

5. Inherited or outsourced code

An acquired system, a team that changed, a vendor that delivered and left. Before taking on the risk, it’s worth knowing what’s inside.

When it isn’t the best choice

• When the question is “what does an outside attacker see?” — to validate the exposed surface, black box answers better and faster.
• When the budget is tight and the application is large — a grey box test focused on authorization and business logic usually returns more per hour.
• When there is no code access — for example, a third-party SaaS you use. Then the possible test is black or grey box, within the vendor’s rules.

What to require from whoever reads your code

Handing over the code means handing over the map of your system. Before granting access, require: an NDA signed before any access; read-only, time-limited access; no copies outside the agreed environment; and verified disposal at the end of the project. A serious firm accepts these terms without argument.

How much a white box pentest costs

At No Vuln, pentests are contracted by the hour, at US$ 150 to US$ 250 per hour. Because white box includes code reading on top of testing, it usually needs larger packages: the Deep Dive (50h), US$ 7,500 to US$ 12,500, for one product or critical module, and the Full Scope (100h+), from US$ 15,000, for larger systems or several applications. The hours depend on the size of the code in scope and the number of critical flows.

For market context, see how much a pentest costs in Brazil and pentest cost by B2B SaaS size.

How to combine white box with grey box and black box

The approaches complement each other. A common setup in mature SaaS and fintech: white box on critical modules and on every major architecture change; grey box as the recurring test of the whole application; black box to track the exposed surface between cycles. That puts depth where risk is highest without leaving the rest uncovered.

What to do now

1. List the modules where a flaw would cost the most (money, personal data, permissions).
2. Check when someone from outside last read that code with an attacker’s mindset.
3. Look for secrets in the repository and its history — and rotate any you find.
4. Add SAST and dependency checks to CI as a continuous safety net.
5. For critical modules, plan a white box pentest before the next major release.

For the technical scope of SaaS pentesting, see SaaS penetration testing. To talk about your case: talk to a researcher — mutual NDA before the first technical call.