Grey-box pentesting: which access to provide, and why

In a grey-box test, the pentester gets part of what a legitimate user knows: test accounts, often the API documentation, sometimes an architecture diagram. No source code. It sits between black box and white box, and it is our default for web application audits.

The reason fits in one sentence: most serious flaws in a business application sit behind the login page.

What you provide

It depends on the scope.

For a web application or an API, ideally one account per role (user, manager, administrator…) and, if your platform serves several customers, two separate organisations, each with its own accounts. Add the API documentation if it exists (an OpenAPI file or a Postman collection is enough) and a staging environment filled with fake data. Testing in production is possible too, with rules written down beforehand.

For an internal network and Active Directory, the starting point is a standard domain user account and a workstation, on site or through remote access. That is the scenario of an employee whose password was phished, or a laptop infected by an attachment.

For a cloud environment, a read-only account is used to review the configuration, and a standard user account for targeted tests.

In every case, these accounts are created for the audit and disabled right after.

Why it is often the best balance between depth and budget

Pentest time is counted in days. In black box, a good part of it goes into finding a way in. In grey box, you walk straight in, and that time goes into testing what the application does with your data.

That is where most of the risk is. Broken access control ranks first in the OWASP Top 10 for web applications, and in the API Security Top 10, three of the top five categories are about authorisation. None of them can be tested properly without accounts.

What two accounts let you test

A simple example. An invoicing platform, two customer companies, A and B. The pentester is logged in as a user of A.

They download one of A’s invoices and look at the request: /api/invoices/18342. They swap the number for one of B’s invoices. If the server returns it, that’s a horizontal access control flaw, called IDOR or BOLA depending on who you ask. It is common, and it is serious: any customer can read every other customer’s data. An automated scanner won’t see it, because the response is perfectly valid from a technical point of view.

With several roles, the pentester also tests vertical access: can a plain user call an admin function if they know its URL? And access to object properties: if you add "role": "admin" to the request that updates your own profile, does the server accept it? That last one, mass assignment, happens more often than you’d think with frameworks that bind incoming fields straight onto database objects.

Then there is business logic: using the same discount code twice, confirming an order without going through payment, inviting a user into an organisation that isn’t yours. These tests require understanding the application, and so being able to use it.

“It’s not realistic, an attacker wouldn’t have an account”

It’s the most common objection, and it doesn’t hold for long. On a SaaS product, anyone can often sign up, or become a customer. On an internal network, a phished account is the most common starting point for ransomware attacks. Your employees’ credentials may already be circulating in data leaks.

Grey box answers a more useful question than “can someone get in?”: once an attacker has a foot in the door, how far can they go? In an Active Directory, that is exactly what the audit measures: which paths lead from a plain user account to administrative rights.

Its limits

Without the code, some flaws stay invisible or very hard to prove: a hidden parameter the interface never sends, a password reset token generated predictably, a secret hard-coded in the source, a race condition that triggers once in a thousand attempts. That is white box territory.

Grey box doesn’t replace a look at your external surface either. A flawless application hosted next to a forgotten server still leaves the company exposed.

Preparing a grey-box audit

A few things save everyone time:

• create the test accounts a few days before the start, and check that they work;
• fill staging with realistic fake data (an empty invoice doesn’t let you test much);
• warn the teams watching the alerts, so they don’t block the audit thinking it’s an attack;
• decide beforehand whether the web application firewall stays on during testing or whether the pentester’s addresses are allowed through. Both choices make sense, but they don’t measure the same thing.

Our web application pentests and Active Directory pentests follow this approach. The quote form suggests it by default, and Penetration testing (pentest): approaches and methodology places grey box among the other approaches.