Home / Knowledge hub / Grey-box testing
Knowledge hub
Grey-box testing
Testing an app with some inside knowledge, such as accounts and docs, but not the code.
What it means
Grey-box testing sits between two other approaches. The tester is given some inside knowledge, usually test accounts, API documentation or an architecture sketch, but not the source code. They test the running application with that head start. This is the position of a customer, partner or contractor, who already knows the product from the outside.
With a signed-in account the test can reach the parts of an app a stranger never sees: the dashboard, the billing page, the admin tools. That is where most business data and most business logic live. Source code is the one thing the tester does not have in this mode.
Why it matters
Real attackers are often not strangers. A customer, a partner or a former employee holds an account and knows how the product works. Grey-box testing models that person, and it finds flaws that need a login to reach, such as one account reading another account's records.
It is also efficient. Without accounts, a tester spends most of the time trying to get in. With them, time goes to testing what lies behind the door. For many web apps and APIs it gives the best balance of realism, cost and coverage. Compare black-box and white-box testing.
How it shows up
You meet it as a pentest where the client supplies two or more accounts at different permission levels, API specifications and perhaps a short walk-through of the product. The tester then checks sign-in, session handling, access control and business rules in the running app.
Mistakes: supplying only one account, so cross-account access cannot be tested, or accounts with so little data that nothing meaningful can be read. Provide at least two accounts in separate organisations with real-looking data, and say what the app is meant to allow. Also see authenticated testing.
Questions people ask
Grey-box testing, answered
What is the difference between black-box, grey-box and white-box?
Black-box has no inside knowledge. Grey-box has accounts and documents. White-box adds the source code.
The more the tester knows, the more the test can cover in the time available.
What do I need to give a grey-box tester?
Test accounts at each permission level, ideally in more than one organisation, plus API documentation and any known limits on what may be tested.
A test environment with realistic data helps.
Does grey-box find things black-box cannot?
Yes. Flaws behind a login, such as broken object-level access or abuse of a business rule, are out of reach without an account.
Black-box still suits checking what an outsider sees.
Is grey-box testing more expensive?
Not necessarily. It usually saves time spent on getting in, so effort goes into the parts of the app that hold your data.
Cost depends on app size and scope more than on the box colour.
Can grey-box testing be automated?
Partly. Tools can sign in, crawl and probe authenticated pages. Judgement about business rules is harder to automate.
Cyberlop runs black-box, grey-box and white-box testing.
Sources
Where this comes from
Related
Terms that sit next to this one
Black-box testing
Testing an app from outside, with no access to the source code.
White-box testing
Testing with access to the source code, not just the running application.
Authenticated testing
Testing the parts of an application that only signed-in accounts can reach.
Cross-account access
One signed-in account reaching another account's data or functions.
Web application penetration testing
A pentest focused on a web app, its APIs and the logic behind them.
What can a signed-in account reach?
Grey-box is where we check what each signed-in account can reach that it should not, and keep the request and response as proof. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.