White-box testing in plain English
In a penetration test, experts attack systems with permission in order to find vulnerabilities. How much they know in advance determines the type of test. In black-box testing, they know almost nothing – just like an outside attacker. In gray-box testing, they receive selected information. In white-box testing, everything is out in the open: the “box” is transparent, so to speak.
An analogy: a building inspector who only looks at a house from the outside will spot cracks in the facade. An inspector with blueprints, keys, and access to the basement will also find the damp wall behind the cabinet and the corroded pipe behind the plaster. That is exactly the difference the white-box approach makes.
How white-box testing works
What the testing team receives depends on what is being tested. Typical items include:
- Documentation: architecture diagrams, network diagrams, data flows, and interface descriptions.
- Access: test accounts for all roles – from regular users to administrators.
- Source code: for applications, the program code – often combined with a manual code review, in which experts read through the code.
- Configurations: for example, of servers, cloud services, firewalls, or central user management such as Active Directory.
- Contacts: experts from development or operations who can answer questions quickly.
With this knowledge, the team can zero in on the sensitive spots: Where are permissions checked? How are passwords stored? Which functions are hidden but still reachable? Automated code analysis (SAST) helps spot potential issues quickly. Hands-on testing of the running system then confirms whether a finding can actually be exploited.
A practical example
A software vendor is developing an online portal through which municipal utilities provide consumption data to their customers. Before go-live, it commissions a white-box test. The testing team receives the source code, an architecture diagram, and test accounts for all roles.
In the code, the team comes across an export function that a developer created for testing and never removed. It isn’t linked anywhere and doesn’t check who is calling it – anyone who knows the address can download the consumption data of all customers. From the outside, it would have been hard to spot. The team also finds an access key for cloud storage hard-coded in the source code.
Both problems are fixed before launch. A retest confirms the fixes, and the portal goes live without these leftovers.
Why does this matter for businesses?
White-box testing makes particularly efficient use of the testing time. The testing team doesn’t have to laboriously guess anything and can focus on the actual testing. This also brings to light vulnerabilities that an attacker would only find after a long search or with insider knowledge.
This matters most for critical applications that handle sensitive data, payment functions, or control functions. Standards and regulations also call for security testing: ISO/IEC 27001:2022 includes a control in Annex A on security testing in development and acceptance, and the Cyber Resilience Act requires manufacturers of products with digital elements – that is, connected devices and software – to carry out regular security testing. This obligation applies from December 11, 2027.
The downside: white-box testing doesn’t reflect what an outsider without prior knowledge can see. If that is exactly what you want to know, combine it with a black-box approach.
What to look out for
- Clarify the goal: Do you want to find as many vulnerabilities as possible or simulate the perspective of an external attacker? The type of test depends on the answer.
- Prepare documentation: Provide current documentation, access, and the right version of the code – outdated diagrams cost testing time.
- Address confidentiality: Agree in advance on how source code and credentials will be securely handed over, stored, and deleted.
- Choose the right time: Ideally, test before go-live or after major changes – at that point, fixing issues is still comparatively inexpensive.
- Provide direct contacts: Name contacts from your development team so that questions can be resolved quickly.
- Have remediation verified: Schedule a retest after the fixes so you can provide evidence that the issues have been resolved.
How Rootsektor can help
Black box, gray box, or white box: in our Penetration Testing engagements, we choose the type of test that fits your goal and the system under test. White-box tests of applications can be combined with Code Review & Reverse Engineering. On request, we sign a non-disclosure agreement in advance. After scoping, you’ll receive a fixed-price quote within 24 hours (on business days) – you can request it via our Pentest Quote page.