Juice Shop: 13 vulnerabilidades detectadas y cero reportes abiertos

Un análisis reciente sobre Juice Shop, la aplicación web insegura mantenida por OWASP, revela 13 vulnerabilidades críticas en su versión 20.2.0, pero ninguna de ellas se ha convertido en un reporte de seguridad formal. El autor explica que esta omisión es intencional: el proyecto está diseñado para ser vulnerable y servir como entorno de aprendizaje, no como software de producción.

El diseño como vulnerabilidad

El texto detalla un barrido estático que identificó fallos como inyección de SQL en las rutas de inicio de sesión y búsqueda, uso de eval en el nombre de usuario, políticas CORS con comodín por defecto y claves RSA de JWT expuestas en el código fuente. Otros hallazgos incluyen contraseñas administrativas sembradas en archivos de configuración, fallos de IDOR en la canasta de compra y redirecciones abiertas.

Para contrastar, se analizó también WebGoat, otro laboratorio de seguridad, donde se encontraron 11 vulnerabilidades similares, incluyendo inyección de XML y secretos JWT accesibles. En ambos casos, los desarrolladores documentan explícitamente en los archivos de seguridad que estas explotaciones son parte de los desafíos del curso y no deben reportarse como incidentes reales.

Volumen frente a juicio

El punto clave no es la cantidad de fallos, sino el contexto. En un repositorio de código abierto real, como Formbricks o Cal.com, estos hallazgos requerirían un protocolo de reporte estricto y corrección. En un entorno de práctica, reportar cada fallo sería ruido inoperante. El autor argumenta que la diferencia radica en la capacidad de distinguir entre un error de producción que exige parche urgente y un sink didáctico que forma parte del currículo.

Esta distinción es crucial para los equipos de seguridad. La automatización con modelos de lenguaje puede generar listas extensas de posibles vulnerabilidades, pero sin supervisión humana, los equipos corren el riesgo de saturar sus trackers con falsos positivos o, peor aún, de tratar un laboratorio como un sistema crítico. La herramienta no sustituye el juicio experto: saber cuándo callar y cuándo abrir un ticket es una competencia profesional esencial para evitar la fatiga de alertas y mantener la señal a ruido en las operaciones de AppSec.