OWASP Top 10 (2025): referencia rápida.
La edición actual, en lenguaje claro: qué ha cambiado desde 2021 y qué significa realmente cada categoría para tu código.
Si la lista que estás usando todavía empieza por «Broken Access Control, Cryptographic Failures, Injection...» en el orden de 2021, está desactualizada. El OWASP Top 10:2025 es la edición actual, y la reordenación no es cosmética: hubo categorías que se movieron, una se fusionó con otra y apareció por primera vez una categoría totalmente nueva. Aquí tienes la lista completa con lo que significa en la práctica, no solo el nombre.
La lista de 2025
| Puesto | Categoría | Qué significa | Novedad 2025 |
|---|---|---|---|
| A01 | Pérdida de control de acceso (Broken Access Control) | Aproximadamente 1 de cada 27 aplicaciones analizadas presenta al menos uno de los 40 CWE de esta categoría. La falsificación de peticiones del lado del servidor (SSRF) queda ahora integrada aquí. | Sigue siendo la número 1, igual que en 2021. |
| A02 | Configuración de seguridad incorrecta (Security Misconfiguration) | Credenciales por defecto, páginas de error detalladas activas en producción, funciones innecesarias habilitadas, cabeceras de seguridad ausentes: lo aburrido que al final resulta ser lo que más importa. | Saltó del puesto 5 (2021) al 2. |
| A03 | Fallos en la cadena de suministro del software (Software Supply Chain Failures) | Paquetes de npm comprometidos y pipelines de build envenenados, no solo la versión antigua de una biblioteca. | Ampliación de los «Vulnerable and Outdated Components» de 2021. |
| A04 | Fallos criptográficos (Cryptographic Failures) | Cifrado débil o ausente para los datos en tránsito y en reposo, claves incrustadas en el código y algoritmos obsoletos todavía en producción. | — |
| A05 | Inyección (Injection) | Inyección de SQL, NoSQL, comandos del sistema operativo y plantillas. | La categoría clásica, ahora sin SSRF dentro. |
| A06 | Diseño inseguro (Insecure Design) | Ausencia de modelado de amenazas, sin requisitos de seguridad recogidos desde el principio. Consulta nuestro recorrido por STRIDE para detectar esto antes. | Riesgo introducido antes de escribir una sola línea de código. |
| A07 | Fallos de autenticación (Authentication Failures) | Políticas de contraseñas débiles, ausencia de autenticación multifactor, tokens de sesión que no caducan cuando deberían. | — |
| A08 | Fallos de integridad del software o de los datos (Software or Data Integrity Failures) | Confiar en actualizaciones, plugins o pipelines de CI/CD sin verificar su integridad. | Detrás de varios ataques a la cadena de suministro de gran repercusión. |
| A09 | Fallos de registro y alertas de seguridad (Security Logging and Alerting Failures) | Brechas que pasan desapercibidas durante meses porque no se registró nada, o porque los registros existían pero nadie los vigilaba. | — |
| A10 | Gestión incorrecta de condiciones excepcionales (Mishandling of Exceptional Conditions) | 24 CWE que cubren el manejo inadecuado de errores, los errores de lógica y los sistemas que «fallan en abierto» (fail open), concediendo acceso o saltándose una comprobación cuando algo va mal en lugar de denegar por defecto. | Totalmente nueva en 2025, con 24 CWE. |
Qué cambió realmente desde 2021
Hay tres cosas que conviene interiorizar si aprendiste la lista de 2021: la Configuración de seguridad incorrecta se volvió mucho más peligrosa en relación con todo lo demás (del 5 al 2), los Componentes vulnerables crecieron hasta convertirse en la categoría más amplia de Fallos en la cadena de suministro para reflejar incidentes reales en el tooling de compilación y los registros de paquetes, y la Gestión incorrecta de condiciones excepcionales es terreno genuinamente nuevo: trata de lo que hace tu código cuando algo va mal, no de lo que hace cuando todo va bien.
Esta no es la misma lista que el Top 10 de LLM
OWASP mantiene un Top 10 para aplicaciones de LLM aparte, y ambas listas se confunden constantemente porque comparten editor y formato. La lista de aplicaciones web de arriba asume una aplicación cliente-servidor tradicional con una base de datos detrás; la lista de LLM asume un modelo que lee texto no confiable y a veces actúa en función de él. La inyección de prompts (prompt injection), la entrada número 1 de la lista de LLM, no encaja limpiamente en ninguna categoría concreta de aquí, aunque comparte ADN tanto con A05 (Inyección) como con A06 (Diseño inseguro): es un problema con forma de inyección que la validación de entradas habitual no puede resolver del todo, que es justo el tipo de hueco que el modelado de amenazas debería detectar antes de salir a producción. Si estás construyendo un producto que es una aplicación web normal con una funcionalidad de LLM añadida encima —que es lo que describe a la mayoría de productos de IA en 2026— necesitas ambas listas, no una en lugar de la otra.
Cómo usar de verdad esta lista
El Top 10 es una herramienta de priorización, no una lista de verificación que marcas una vez. Mapea cada categoría contra tu propia aplicación durante una sesión de modelado de amenazas, prueba las más relevantes para tu stack con herramientas como Burp Suite u OWASP ZAP, y revisa el mapeo cada vez que añadas una nueva dependencia, un nuevo flujo de autenticación o una nueva integración: ahí es donde suele aparecer discretamente la siguiente entrada de esta lista.
Una forma concreta de empezar: elige las tres categorías con más probabilidades de afectar a tu stack en particular —para un producto SaaS típico suelen ser A01 (Control de acceso), A02 (Configuración incorrecta) y A03 (Cadena de suministro)— y dedica una tarde enfocada a cada una en lugar de intentar auditar las diez a la vez. Profundizar en las categorías que realmente te aplican vale más que una pasada superficial por las diez.