White Box Testing

What is White Box Testing

White box testing is an approach that allows testers to inspect and verify the inner workings of a software system—its code, infrastructure, and integrations with external systems. White box testing is an essential part of automated build processes in a modern Continuous Integration/Continuous Delivery (CI/CD) development pipeline.

White box testing is often referenced in the context of Static Application Security Testing (SAST), an approach that checks source code or binaries automatically and provides feedback on bugs and possible vulnerabilities.

White box testing provides inputs and examines outputs, considering the inner workings of the code

White Box Testing Pros and Cons

×

Nov 26 Upcoming Webinar

The True Cost of API Insecurity and Bot Attacks in 2024

Register Now

Black Box and White Box Testing

White box testing is often contrasted with black box testing, which involves testing an application from the user’s perspective without any knowledge of its implementation:

• White box testing can uncover structural problems, hidden errors and problems with specific components.
• Black box testing checks that the system as a whole is working as expected.

Grey Box Testing

White box testing involves complete knowledge of the inner workings of a system under test and black box involves no knowledge. Grey box testing, however, is a compromise – testing a system with partial knowledge of its internals. It is most commonly used in integration testing, end-to-end system testing, and penetration testing.

Grey box testing combines inputs from developers and testers and can result in more effective testing strategies. It reduces the overhead required to perform functional testing of a large number of user paths, focusing testers on the paths most likely to affect users or result in a defect.

Grey box testing combines the benefits of black box and white box testing:

• Ensuring that tests are performed from the user’s perspective, like in black box testing.
• Leveraging inside knowledge to focus on the problems that matter most, and to identify and resolve internal weaknesses of the system, like in white box testing.

In the world of Application Security Testing, the grey box testing approach is called Interactive Application Security Testing (IAST). IAST combines:

• SAST — which performs white box testing by evaluating static application code.
• Dynamic Application Security Testing (DAST) — which performs black box testing, by interacting with running applications and discovering faults and vulnerabilities like a user or external attacker would.

Types of White Box Testing

White box testing can take several forms:

• Unit testing — tests written as part of the application code, which test that each component is working as expected.
• Mutation testing — a type of unit testing that checks the robustness and consistency of the code by defining tests, making small, random changes to the code and seeing if the tests still pass.
• Integration testing — tests specifically designed to check integration points between internal components in a software system, or integrations with external systems.
• White box penetration testing — an ethical hacker acts as a knowledgeable insider, attempting to attack an application based on intimate knowledge of its code and environment.
• Static code analysis — automatically identifying vulnerabilities or coding errors in static code, using predefined patterns or machine learning analysis.

What Does White Box Testing Focus On?

White box tests can focus on discovering any of the following problems with an application’s code:

• Security gaps and vulnerabilities — checking to see if security best practices were applied when coding the application, and if the code is vulnerable to known security threats and exploits.
• Broken or poorly structured paths — identifying conditional logic that is redundant, broken or inefficient.
• Expected output — executing all possible inputs to a function to see if it always returns the expected result.
• Loop testing — checking single loops, concatenated loops and nested loops for efficiency, conditional logic, and correct handling of local and global variables.
• Data Flow Testing (DFT) — tracking variables and their values as they pass through the code to find variables that are not correctly initialized, declared but never used, or incorrectly manipulated.

Testing Techniques and Code Coverage

One of the main goals of white box testing is to cover the source code as comprehensively as possible. Code coverage is a metric that shows how much of an application’s code has unit tests checking its functionality.

Within code coverage, it is possible to verify how much of an application’s logic is actually executed and tested by the unit test suite, using concepts like statement coverage, branch coverage, and path coverage. These concepts are discussed in more detail below.

Statement Coverage

Statement coverage is a white box testing technique that ensures all executable statements in the code are run and tested at least once. For example, if there are several conditions in a block of code, each of which is used for a certain range of inputs, the test should execute each and every range of inputs, to ensure all lines of code are actually executed.

Statement coverage helps uncover unused statements, unused branches, missing statement that are referenced by part of the code, and dead code left over from previous versions.

Branch Coverage

Branch coverage maps the code into branches of conditional logic, and ensures that each and every branch is covered by unit tests. For example, if there are several nested conditional statements:

if X then..
   if Y then..
      A
      B
   else
      if Z then..
         C
      else..
         D

A, C, and D are conditional branches, because they occur only if a condition is satisfied. B is an unconditional branch, because it is always executed after A. In a branch coverage approach, the tester identifies all conditional and unconditional branches and writes code to execute as many branches as possible.

Path Coverage

Path coverage is concerned with linearly independent paths through the code. Testers draw a control flow diagram of the code, such as the example below.

Control flow diagram used to design tests in a path coverage approach

In this example, there are several possible paths through the code:

• 1, 2
• 1, 3, 4, 5, 6, 8
• 1, 3, 4, 7, 6, 8
• etc.

In a path coverage approach, the tester writers unit tests to execute as many as possible of the paths through the program’s control flow. The objective is to identify paths that are broken, redundant, or inefficient.

Imperva Runtime Application Self Protection

Runtime Application Self Protection (RASP) complements white box and black box testing by adding an extra layer of protection once the application is already in production or in a realistic staging environment.

RASP has the following benefits:

• It helps test applications in-depth during fast, agile development cycles.
• It tests for unanticipated inputs, inspects and controls the system’s response.
• It provides analysis and detailed information on weaknesses and vulnerabilities, helping you quickly respond to attacks.

Imperva RASP provides these benefits, keeping your applications protected and giving you essential feedback for eliminating any additional risks. It requires no changes to code and integrates easily with existing applications and DevOps processes, protecting you from both known and zero-day attacks.

In addition, Imperva provides multi-layered protection to make sure websites and applications are available, easily accessible and safe. The Imperva application security solution includes:

• DDoS Protection — maintain uptime in all situations. Prevent any type of DDoS attack, of any size, from preventing access to your website and network infrastructure.
• CDN — enhance website performance and reduce bandwidth costs with a CDN designed for developers. Cache static resources at the edge while accelerating APIs and dynamic websites.
• Cloud WAF — permit legitimate traffic and prevent bad traffic. Safeguard your applications at the edge with an enterprise‑class cloud WAF.
• Gateway WAF — keep applications and APIs inside your network safe with Imperva Gateway WAF.
• Attack analytics — mitigate and respond to real security threats efficiently and accurately with actionable intelligence across all your layers of defense.
• Account takeover protection — uses an intent-based detection process to identify and defends against attempts to take over users’ accounts for malicious purposes.
• API security — protects APIs by ensuring only desired traffic can access your API endpoint, as well as detecting and blocking exploits of vulnerabilities.
• Bot Management — analyzes your bot traffic to pinpoint anomalies, identifies bad bot behavior and validates it via challenge mechanisms that do not impact user traffic.