Estos tres términos describen cuánto sabe el tester sobre el objetivo antes de empezar y, por tanto, hasta dónde puede llegar de forma realista en el tiempo disponible. Son grados de conocimiento, no una clasificación de calidad.
En una prueba black-box, el tester parte de poco o ningún conocimiento interno, a menudo solo un dominio o un rango de IP, y trabaja como lo haría un atacante externo. Es realista para simular a un oportunista de fuera. Pero el tiempo, que es fijo, se va en un descubrimiento al que un atacante real podría dedicar meses, así que pueden escaparse fallos reales pero más profundos simplemente por falta de tiempo.
El grey-box da al tester un conocimiento parcial, normalmente cuentas válidas con distintos roles y una especificación de API como OpenAPI/Swagger. Es la opción pragmática por defecto para la mayor parte del trabajo con aplicaciones y API, porque el presupuesto se dedica a encontrar fallos reales y no al reconocimiento. Los fallos de autorización como BOLA/IDOR solo pueden encontrarse con varias cuentas: con un solo token, o sin ninguno, no hay forma de ponerlos a prueba.
Las pruebas white-box (o crystal-box) dan información completa: código fuente, arquitectura, configuración y acceso a las personas implicadas. Permiten la cobertura más profunda y son la elección adecuada cuando necesitas un aseguramiento alto o verificas frente a los niveles superiores de un estándar. OWASP ASVS 5.0 señala que sus niveles más rigurosos pueden requerir precisamente este tipo de acceso a la documentación, el código fuente y la configuración.
Elige según el objetivo de aseguramiento, no según lo que suene más difícil. El black-box encaja con una simulación realista de un atacante externo, el grey-box es la opción eficiente por defecto para evaluaciones web y de API, y el white-box es para revisiones de alto aseguramiento y verificación frente a estándares. Una idea que ya no vale: ASVS 5.0 redefinió el nivel 1, así que el antiguo atajo de que «el L1 de ASVS equivale a un pentest black-box» ya no se sostiene. El nivel de verificación es ahora una decisión basada en el riesgo.
Describen cuánto sabe el evaluador sobre el objetivo antes de empezar, no una clasificación de calidad. La caja negra parte con poco o ningún conocimiento interno; la caja gris aporta conocimiento parcial, como cuentas válidas y una especificación; la caja blanca da acceso completo al código fuente, la arquitectura y la configuración.
La caja gris es la opción pragmática por defecto para la mayor parte del trabajo con aplicaciones y API, porque el presupuesto se dedica a encontrar fallos reales en lugar de al reconocimiento. Importa sobre todo para los fallos de autorización como BOLA/IDOR, que solo pueden encontrarse con varias cuentas de distintos roles: un único token, o ninguno, no permite ponerlos a prueba.
No. OWASP ASVS 5.0 replanteó el nivel 1, así que la vieja equivalencia «ASVS L1 = prueba de penetración de caja negra» ya no se sostiene: el nivel de verificación es ahora una decisión de riesgo, y los niveles de ASVS más altos y rigurosos pueden requerir un acceso de tipo caja blanca al código fuente y la configuración.