El OWASP Top 10:2025 es la octava edición de la lista, y sus diez categorías son: A01 Broken Access Control (control de acceso roto), A02 Security Misconfiguration (configuración insegura), A03 Software Supply Chain Failures (fallas de la cadena de suministro), A04 Cryptographic Failures (fallas criptográficas), A05 Injection (inyección), A06 Insecure Design (diseño inseguro), A07 Authentication Failures (fallas de autenticación), A08 Software or Data Integrity Failures (fallas de integridad), A09 Security Logging and Alerting Failures (fallas de registro y alerta) y A10 Mishandling of Exceptional Conditions (mal manejo de condiciones excepcionales). Hay dos categorías nuevas: A03 y A10. Y la lista se armó revisando 589 CWE, de las que 248 quedaron distribuidas en las diez.
Ver índice de contenidos
Qué cambió respecto de 2021
Cuatro cambios estructurales, y conviene conocerlos porque los identificadores no son equivalentes entre ediciones: citar «A03» sin decir el año es ambiguo.
| Cambio | Detalle |
|---|---|
| Dos categorías nuevas | A03 Software Supply Chain Failures, como expansión de las componentes vulnerables y desactualizadas de 2021, y A10 Mishandling of Exceptional Conditions |
| Dos renombradas | A07 pasó de «Identification and Authentication Failures» a «Authentication Failures»; A09 pasó de «Logging and Monitoring» a «Logging & Alerting» |
| Una consolidación | La falsificación de peticiones del lado del servidor se fusionó dentro de A01 |
| Un ascenso notable | Configuración insegura subió del quinto puesto al segundo |
El cambio más significativo es A03: que las fallas de la cadena de suministro entren directo al tercer puesto reconoce algo que la práctica ya mostraba, y que el tratamiento defensivo de la cadena de suministro venía señalando: la mayor parte del código que ejecutás no lo escribiste vos.
Cómo se armó la lista
Saber cómo se construye evita dos malentendidos: creer que es un ranking objetivo de riesgo y creer que es arbitraria. El documento se describe a sí mismo como «informado por datos, pero no ciegamente guiado por datos».
En concreto: «rankeamos 12 categorías según los datos aportados, y permitimos que dos fueran promovidas o destacadas por las respuestas de la encuesta a la comunidad». La razón de esa mezcla también está explicada: «solo elegimos ocho de las diez categorías a partir de los datos porque están incompletos. Las otras dos categorías vienen de la encuesta».
Y el alcance creció mucho: «de aproximadamente 30 CWE en 2017, a casi 400 CWE en 2021, a 589 CWE en esta edición». De esas, 248 quedaron distribuidas en las diez categorías.
Qué implica esa metodología
Que la lista refleja lo que se encuentra y lo que la comunidad percibe, no una medición completa del riesgo real. Una categoría puede estar arriba porque es fácil de detectar automáticamente, y otra abajo porque casi nadie la busca. Es una guía de prioridades muy útil y no un veredicto: el riesgo de tu aplicación depende de tu aplicación.
A01 · Control de acceso roto
Se mantiene en el primer puesto. Ocurre cuando la aplicación no verifica que quien pide algo tenga derecho a pedirlo. Es la categoría más amplia y la que más aparece en pruebas reales.
El caso escolar es cambiar un identificador en la dirección:
Tu factura: GET /api/facturas/4821
Cambiás el número: GET /api/facturas/4822 ← ¿te la devuelve?
Si te devuelve la factura de otra persona, el servidor comprobó que
estás autenticado pero NO que ese recurso sea tuyo. Son dos cosas
distintas: autenticación es quién sos, autorización es qué podés hacer.Otras formas frecuentes: acceder a un panel de administración por su dirección directa sin ser administrador, modificar un campo de rol en un formulario, y —desde esta edición— la falsificación de peticiones del lado del servidor, donde se hace que el servidor pida una dirección elegida por el atacante, alcanzando servicios internos que no están expuestos.
La defensa estructural: denegar por defecto y verificar la propiedad del recurso en el servidor, en cada petición. Las comprobaciones en la interfaz no cuentan: se saltean.
A02 · Configuración insegura
Subió del quinto al segundo puesto, y el ascenso tiene sentido: cuanto más componentes tiene un sistema, más configuraciones hay para dejar mal.
Ejemplos concretos, todos frecuentes:
- Credenciales por defecto sin cambiar, en un panel, una base o un dispositivo.
- Mensajes de error detallados en producción, que revelan rutas, versiones y consultas.
- Servicios innecesarios habilitados: cada uno es superficie sin contrapartida.
- Almacenamiento en la nube abierto al público sin querer.
- Cabeceras de seguridad ausentes o mal configuradas.
- Permisos de archivo excesivos en el servidor.
Lo que las une es que ninguna es un error de programación: el código está bien y el sistema está mal armado. Por eso se detectan con revisión de configuración y no con análisis de código, y por eso conviene tener la configuración declarada y versionada en lugar de aplicada a mano.
A03 · Cadena de suministro
La novedad de esta edición y el cambio conceptual más importante. En 2021 la categoría equivalente hablaba de componentes vulnerables y desactualizados —una dependencia con un fallo conocido—. La de 2025 amplía el alcance a los compromisos que ocurren dentro o a través de todo el ecosistema de dependencias y sistemas de compilación.
La diferencia es de naturaleza, no de grado:
| Componente vulnerable (2021) | Falla de la cadena (2025) | |
|---|---|---|
| Qué pasa | Una dependencia tiene un fallo conocido | Alguien introdujo algo malicioso en el camino |
| Cómo se detecta | Comparando versiones contra bases de vulnerabilidades | Mucho más difícil: el paquete es «legítimo» |
| Cómo se mitiga | Actualizando | Procedencia, firma y fijado por resumen |
| Dónde ocurre | En tu lista de dependencias | En el registro, el sistema de compilación o la distribución |
El detalle en profundidad —cómo funcionan la confusión de dependencias y la suplantación de nombres— está en ataques de cadena de suministro, dependency confusion y typosquatting, y los controles defensivos en seguridad de la cadena de suministro de software.
A04 · Fallas criptográficas
No es «no usar cifrado» sino usarlo mal, que es más común. Los casos típicos:
- Datos sensibles en tránsito sin cifrar, o con un tramo sin cifrar. El caso del modo de cifrado flexible en un proxy es exactamente esto: el candado cubre medio camino.
- Contraseñas guardadas con un resumen inadecuado. Un resumen rápido de propósito general no sirve para contraseñas: hay que usar una función diseñada para eso, lenta y con sal.
- Algoritmos obsoletos o versiones viejas del protocolo todavía habilitadas.
- Claves en el repositorio o en la imagen del contenedor.
- Aleatoriedad predecible para tokens y contraseñas temporales.
La regla que resume la categoría: no inventar criptografía y no elegir primitivas por intuición. Para cada problema hay una recomendación publicada, y las hojas de trucos de OWASP tienen una por tema.
A05 · Inyección
La familia clásica: ocurre cuando datos que vienen de afuera se interpretan como instrucciones. Incluye la inyección en bases de datos, la ejecución de comandos del sistema, la inyección en plantillas y el cross-site scripting.
# ✗ El dato se concatena y pasa a ser parte de la instrucción
consulta = "SELECT * FROM usuarios WHERE correo = '" + entrada + "'"
# ✓ El dato viaja como PARÁMETRO: el motor ya sabe qué es instrucción
cursor.execute("SELECT * FROM usuarios WHERE correo = %s", (entrada,))La defensa no es «filtrar caracteres peligrosos» —eso se elude— sino separar instrucción de datos en la propia interfaz: consultas parametrizadas para bases de datos, y codificación según el contexto de salida para el navegador.
Un dato que sorprende: la inyección bajó de puestos en las últimas ediciones. No es que haya desaparecido, es que los marcos de trabajo modernos la previenen por defecto. Aparece cuando alguien se sale del camino recomendado.
A06 a A08
A06 · Diseño inseguro. La única categoría que no se arregla con código: son fallas de diseño, decisiones tomadas antes de programar. Un ejemplo claro es un flujo de recuperación de contraseña basado en preguntas cuya respuesta es pública. No hay parche posible: hay que rediseñar el flujo.
A07 · Fallas de autenticación. Renombrada en esta edición. Cubre permitir contraseñas débiles o filtradas, no limitar los intentos, exponer identificadores de sesión, no invalidar la sesión al cerrarla y flujos de recuperación débiles. Es la categoría que las passkeys atacan de raíz, al eliminar el secreto compartido.
A08 · Fallas de integridad de software o datos. Confiar en algo sin verificar que sea lo que dice ser: una actualización sin firma, datos serializados que se deserializan sin validar, un script cargado desde un tercero sin comprobar su integridad. El blog de Underc0de documentó un caso reciente: la falla crítica en React RSC que permitía ejecución remota de código.
A09 y A10
A09 · Fallas de registro y alerta. El cambio de nombre —de «monitoreo» a «alerta»— es significativo: no alcanza con registrar, hay que avisar. Un sistema que guarda todo en un archivo que nadie mira no cumple. Los síntomas: no registrar los intentos de acceso fallidos, no tener alerta ante patrones anómalos, registros sin la información necesaria para reconstruir qué pasó, y —el peor— registrar datos sensibles o credenciales en texto claro, con lo que el registro se vuelve el objetivo.
A10 · Mal manejo de condiciones excepcionales. La otra categoría nueva, y la más interesante conceptualmente: cubre lo que pasa cuando algo sale mal. Errores que se ignoran en silencio, excepciones capturadas de forma genérica que ocultan el problema real, sistemas que ante una falla quedan en un estado permisivo en lugar de negar, y mensajes de error que filtran información interna.
El patrón que resume la categoría: si la comprobación de permisos falla por un error técnico, el resultado tiene que ser denegar, no permitir. Que una categoría nueva sea sobre el manejo de errores dice bastante sobre dónde se están encontrando los problemas ahora.
Cómo usar la lista
Con una advertencia primero: esto no es una lista de verificación. Es material de concientización para priorizar. El documento pensado para verificar es el estándar de verificación, como se explica en qué es OWASP.
Dicho eso, tres usos donde rinde:
- Como orden de aprendizajeRecorrer las diez categorías reproduciendo cada una en un laboratorio propio. Entender una vulnerabilidad haciéndola funcionar es distinto de leerla.
- Como lenguaje comúnSirve para hablar con quien decide: nombrar la categoría comunica el riesgo sin entrar en detalle técnico.
- Como punto de partida de una revisiónDiez preguntas para hacerle a un sistema antes de profundizar con la guía de pruebas.
Preguntas frecuentes
¿Cuáles son las diez categorías del OWASP Top 10 2025?
Control de acceso roto, configuración insegura, fallas de la cadena de suministro de software, fallas criptográficas, inyección, diseño inseguro, fallas de autenticación, fallas de integridad de software o datos, fallas de registro y alerta de seguridad, y mal manejo de condiciones excepcionales. Es la octava edición de la lista. Dos de esas categorías son nuevas: las fallas de la cadena de suministro, que entran directo en el tercer puesto, y el mal manejo de condiciones excepcionales.
¿Qué cambió respecto de la edición 2021?
Cuatro cosas. Entraron dos categorías nuevas: fallas de la cadena de suministro de software, como expansión de las componentes vulnerables y desactualizadas, y mal manejo de condiciones excepcionales. Se renombraron dos: las fallas de identificación y autenticación pasaron a llamarse solo fallas de autenticación, y las de registro y monitoreo pasaron a ser de registro y alerta. La falsificación de peticiones del lado del servidor se fusionó dentro del control de acceso roto. Y la configuración insegura subió del quinto puesto al segundo.
¿Cómo se decide qué entra en la lista?
Con una mezcla que el propio documento describe como informada por datos pero no ciegamente guiada por datos. Se ordenaron doce categorías según los datos aportados y se permitió que dos fueran promovidas por la encuesta a la comunidad, porque los datos son incompletos: ocho categorías salen de los datos y dos de la encuesta. El alcance de debilidades revisadas creció de unas treinta en 2017 a casi cuatrocientas en 2021 y a quinientas ochenta y nueve en esta edición, de las cuales doscientas cuarenta y ocho quedaron en la lista final.
¿Por qué la cadena de suministro subió tanto?
Porque el problema cambió de naturaleza. La categoría de 2021 hablaba de componentes vulnerables y desactualizados, es decir dependencias con fallos conocidos que se arreglan actualizando. La de 2025 amplía el alcance a compromisos que ocurren dentro o a través de todo el ecosistema de dependencias y sistemas de compilación: alguien introduce algo malicioso en el camino y el paquete parece legítimo. Eso no se detecta comparando versiones y no se mitiga actualizando: hace falta procedencia, firma y fijado por resumen.
¿La inyección dejó de ser importante?
No desapareció, pero bajó de puestos, y la razón es buena: los marcos de trabajo modernos la previenen por defecto con consultas parametrizadas y codificación automática de salida. Aparece cuando alguien se sale del camino recomendado, concatena una consulta a mano o usa una función que no escapa. La defensa nunca fue filtrar caracteres peligrosos, que se elude, sino separar la instrucción de los datos en la propia interfaz: parámetros para las bases de datos y codificación según el contexto de salida para el navegador.
¿Puedo usar el Top 10 como lista de verificación de una auditoría?
No conviene, y el propio proyecto lo aclara: es material de concientización para entender el panorama y priorizar, no un criterio de verificación. No dice qué probar ni cómo, así que una aplicación puede no presentar nada del Top 10 y ser insegura. Para verificar existe el estándar de verificación de seguridad de aplicaciones, con requisitos redactados para responder cumple o no cumple, y para ejecutar las pruebas existe la guía de pruebas de seguridad web, con procedimientos e identificadores citables.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección Seguridad web y en servidores. Hilos de la comunidad sobre vulnerabilidades web concretas y su corrección.
- Underc0de, blog. CVE-2025-55182: falla crítica en React RSC permite ejecución remota de código, 3 de diciembre de 2025. Un caso real de la categoría de integridad.
Documentación oficial
- OWASP. OWASP Top 10:2025. Las diez categorías con sus identificadores y nombres, citados textualmente.
- OWASP. Introduction. La metodología, la cantidad de CWE revisadas, el reparto entre datos y encuesta, y los cambios respecto de 2021.
- OWASP. A01:2025 Broken Access Control. La categoría con más detalle y ejemplos.
- OWASP. A03:2025 Software Supply Chain Failures. La categoría nueva que subió al tercer puesto.
- MITRE. Common Weakness Enumeration (CWE). El catálogo de debilidades sobre el que se construye la lista.