OWASP Top 10 2025: lo que cambió y cómo adaptarte
La actualización 2025 del OWASP Top 10 refleja un ecosistema de amenazas diferente al de 2021. Broken Access Control sigue en el tope, pero aparecen nuevas categorías relacionadas con IA, APIs y supply chain.
El OWASP Top 10 es la referencia más citada en seguridad de aplicaciones web. No es una lista exhaustiva de vulnerabilidades, sino una señal de qué categorías de problemas son más prevalentes y de mayor impacto según datos reales de la industria. La versión 2025 trajo cambios relevantes que todo equipo de desarrollo debería conocer.
Qué hay de nuevo en 2025
Broken Access Control sigue siendo el #1. En el 94% de las aplicaciones evaluadas se encontró alguna forma de control de acceso roto —un número que no ha mejorado desde 2021. Esto incluye escalada de privilegios horizontal (acceder a datos de otro usuario con tu token) y vertical (acceder a funciones de admin sin permisos).
LLM Integration Vulnerabilities es la nueva entrada más discutida. Con la adopción masiva de IA generativa, aparecen vectores que no existían antes: prompt injection en chatbots que procesan input del usuario, exfiltración de datos a través de modelos conectados a bases de datos internas, y confiar en outputs de LLM sin validación antes de ejecutarlos como código.
API Security consolidó las dos entradas separadas de 2021 (Broken Object Level y Function Level Authorization) en una categoría unificada, reflejando que las APIs son ahora la superficie de ataque principal de la mayoría de aplicaciones modernas.
Cómo implementar las defensas en tu equipo
Para Broken Access Control, la solución es dejar de asumir que la lógica del frontend es una defensa real. Cada endpoint de backend debe verificar los permisos del usuario autenticado de forma independiente, sin depender de qué opciones se le mostraron en la interfaz.
Para LLM Integration, el principio es simple pero poco aplicado: nunca ejecutar directamente output de un modelo como instrucción del sistema. Si tu chatbot puede llamar funciones o ejecutar queries, esas llamadas deben pasar por una capa de validación que limite qué operaciones son permitidas, independientemente de lo que el modelo sugiera.
Para APIs, lo mínimo no negociable es: autenticación en todos los endpoints, autorización por objeto (no solo por rol), rate limiting diferenciado por usuario, y logs de acceso con suficiente contexto para detectar abuso.
Dónde empezar si partes de cero
OWASP publica WebGoat y Juice Shop, dos aplicaciones vulnerables diseñadas para practicar. Si tienes un equipo de desarrollo, una hora de ejercicios con Juice Shop enseña más que tres presentaciones sobre "seguridad en el desarrollo". Complementa con el OWASP SAMM para evaluar la madurez actual de tus prácticas de seguridad y priorizar dónde invertir esfuerzo.