Before a single test begins, one scoping decision shapes the entire engagement more than almost anything else: how much access does the tester start with? Black box, grey box, and white box aren't just jargon — they simulate genuinely different attackers, and picking the wrong one means paying for a test that answers the wrong question.
Black box: the stranger at the door
No credentials, no internal knowledge — just a public-facing target. This is useful for answering one specific question: what can a complete outsider see and reach? It's a reasonable starting point, but it also means a lot of testing time goes into reconnaissance instead of depth, and anything behind a login screen barely gets touched.
Grey box: the far more common real attacker
A standard low-privilege account, same as any customer or employee. This is the scenario we recommend most often, because it's the scenario that actually happens — a phished credential, a leaked API key, a free-tier signup. Grey box testing spends its time where it matters: inside the application, testing what a semi-trusted user can do that they shouldn't be able to.
White box: the deepest read, on code
Full source access. This isn't really a different flavor of the same test — it's a different discipline entirely (secure code review), better suited to catching the vulnerabilities that never manifest in obvious external behavior.
Our default recommendation
For most production applications, grey box VAPT paired with a secure code review on the highest-risk modules gives the best coverage per rupee spent. Black box has its place for a pure perimeter check; white box alone misses the runtime behavior that only shows up when the app is actually running.