What is gray-box testing?

Gray-box testing in plain English

One of the ways penetration tests differ is how much the testing team knows in advance. In black-box testing, the team starts with almost no information; in white-box testing, it gets comprehensive insight, all the way down to the source code. Gray-box testing (also spelled “grey-box”) lies in between – hence the name.

A comparison: imagine you’re having the security of your office building tested. With the black-box approach, the tester stands outside the fence and first has to find the entrances. With the gray-box approach, they receive a visitor badge and a floor plan. They skip the search and can immediately check whether a visitor can get into rooms that should be off-limits to them.

In IT, this is often the most important question: how much damage can someone do once they have a foot in the door? Think of an attacker with stolen credentials or a malicious insider.

How gray-box testing works

1. Scoping: Together with the testing team, you define what will be tested (the scope) and which information the team will receive.
2. Provisioning: Typical items include test accounts with different roles (such as customer, clerk, and administrator), API documentation, network diagrams, or a standard workstation for internal tests.
3. Testing: The testing team attacks using the methods of real attackers – from a realistic starting point. For example, it checks whether a customer can see other customers’ orders or whether a regular user account can obtain administrator rights.
4. Report: You receive the findings with a risk rating and concrete remediation recommendations.

Typical scenarios include:

• Web application or application programming interface (API) with a login: With at least two accounts per role, testers can check whether users can access other users’ data. This vulnerability is known as IDOR.
• Assumed breach: The test starts with an ordinary user account on the internal network, as if a phishing attack had already succeeded.
• Cloud environment: The testing team receives an identity with typical permissions and checks how far that access can be expanded.

A practical example

Here’s a typical scenario: A payroll services provider operates a web portal where business customers maintain their employees’ data. For the penetration test, it provides two test accounts each for the roles “Clerk” and “Client Admin,” spread across two test companies created specifically for this purpose. Because the testing team doesn’t spend any time guessing credentials, it can thoroughly examine the areas behind the login.

In the process, one thing stands out: by modifying a request, a client admin can create users in another company. A pure black-box test without a valid account would hardly have made it as far as this function.

Why does this matter for businesses?

The time available for a penetration test is limited. The less of it goes into pure information gathering, the more is left for depth. That’s why the gray-box approach usually offers the best balance between depth of testing and effort.

It is also realistic. Many attacks begin with stolen credentials, for example through phishing or data leaks. A gray-box test reflects exactly this situation. In addition, flaws in permissions and business logic often only become visible with valid accounts.

The approach has one limitation: it doesn’t show how an attacker gains initial access in the first place. If you want to know that as well, combine it with a black-box component, such as an external test without prior knowledge.

What to look out for

• Define the goal: Clarify which attacker scenario the test should simulate – for example, a customer, an employee, or a service provider.
• Realistic test accounts: Provide separate accounts for each role with realistic permissions – not blanket administrator rights.
• Two accounts per role: This is the only way to test access across user and tenant boundaries – that is, between different customer companies on the same platform.
• Provide documentation: API documentation, network diagrams, and your role and permission model speed up the test.
• Clarify the environment: Decide whether testing takes place in the production environment or a test environment and which test data will be used.
• Clean up: Deactivate or delete the test accounts once the test is complete.

How Rootsektor can help

For most web applications, APIs, and internal networks, we recommend a gray-box approach. During scoping, we clarify which information and test accounts make sense – tailored to your goal and your budget. You can learn more about test types and the process on our Penetration Testing page. After scoping, you’ll receive a fixed-price quote within 24 hours (on business days); you can request it via our Pentest Quote page.