These three terms describe how much the tester knows about the target before starting, and therefore how deep they can realistically go in the time available. They are points on a scale of knowledge, not a ranking of quality.
In a black-box test the tester starts with little or no inside knowledge (often just a domain or an IP range) and works as an external attacker would. This is realistic for modelling an opportunistic outsider. But the fixed time-box goes on discovery that a real attacker could spend months on, so real flaws that sit deeper can be missed simply for lack of time.
Grey-box gives the tester partial knowledge, typically valid accounts for each role and an API spec such as OpenAPI/Swagger. It is the practical default for most application and API work, because the budget goes on finding real flaws rather than on reconnaissance. Authorisation flaws such as BOLA/IDOR can only be found with several accounts; with one token, or none, there is no way to exercise them.
White-box (or crystal-box) testing gives full information: source code, architecture, configuration and access to the people involved. It allows the deepest coverage and is the right choice when you need high assurance or are verifying against the higher levels of a standard. OWASP ASVS 5.0 notes that its more rigorous levels may require exactly this kind of access to documentation, source and configuration.
Choose by assurance objective, not by which option sounds hardest. Black-box suits a realistic simulation of an external attacker; grey-box is the efficient default for web and API assessments; white-box is for high-assurance reviews and verification against standards. One outdated idea: ASVS 5.0 reframed Level 1, so the old shorthand 'ASVS L1 equals a black-box pentest' no longer holds. The verification level is now a risk decision.
They describe how much the tester knows about the target before starting, not a ranking of quality. Black-box starts with little or no inside knowledge; grey-box gives partial knowledge such as valid accounts and a spec; white-box gives full source, architecture and configuration.
Grey-box is the practical default for most application and API work, because the budget goes on finding real flaws rather than on reconnaissance. It matters most for authorisation flaws such as BOLA/IDOR, which can only be found with accounts in several roles. A single token, or none, can't exercise them.
No. OWASP ASVS 5.0 reframed Level 1, so the old shorthand 'ASVS L1 equals a black-box pentest' no longer holds. The verification level is now a risk decision, and the higher, more rigorous ASVS levels may require white-box access to source and configuration.