# OWASP Top 10 2025 explicado con ejemplos

**Categoría:** Hacking ético · **Nivel:** Intermedio · **Lectura:** 13 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/hacking/owasp-top-10-2025-explicado/

## Respuesta rápida

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.

## 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](../../devops-cloud/seguridad-de-la-cadena-de-suministro-de-software/index.md) 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:

```text
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](../ataques-de-cadena-de-suministro/index.md), y los controles defensivos en [seguridad de la cadena de suministro de software](../../devops-cloud/seguridad-de-la-cadena-de-suministro-de-software/index.md).

## 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](../../desarrollo-web/que-es-cloudflare-y-como-configurarlo/index.md) 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](../que-es-owasp/index.md) 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*.

```python
# ✗ 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](../passkeys-autenticacion-sin-contrasena-y-zero-trust/index.md) 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](https://blog.underc0de.org/cve-2025-55182-falla-critica-en-react-rsc-permite-rce/).

## 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](../que-es-owasp/index.md).

Dicho eso, tres usos donde rinde:

1. **Como orden de aprendizaje** Recorrer las diez categorías reproduciendo cada una **en un laboratorio propio**. Entender una vulnerabilidad haciéndola funcionar es distinto de leerla.
2. **Como lenguaje común** Sirve para hablar con quien decide: nombrar la categoría comunica el riesgo sin entrar en detalle técnico.
3. **Como punto de partida de una revisión** Diez preguntas para hacerle a un sistema antes de profundizar con la guía de pruebas.

> Todo lo anterior se practica en un entorno propio y con autorización. El marco está en [hacking ético: fundamentos, metodología y laboratorio seguro](../fundamentos-hacking-etico/index.md). Probar cualquiera de estas categorías en un sistema ajeno sin permiso escrito no es aprendizaje: es un delito.

## 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

1. **Underc0de, foro.** [Sección Seguridad web y en servidores](https://underc0de.org/foro/seguridad-en-servidores/). Hilos de la comunidad sobre vulnerabilidades web concretas y su corrección.
2. **Underc0de, blog.** [CVE-2025-55182: falla crítica en React RSC permite ejecución remota de código](https://blog.underc0de.org/cve-2025-55182-falla-critica-en-react-rsc-permite-rce/), 3 de diciembre de 2025. Un caso real de la categoría de integridad.

### Documentación oficial

1. **OWASP.** [OWASP Top 10:2025](https://owasp.org/Top10/2025/). Las diez categorías con sus identificadores y nombres, citados textualmente.
2. **OWASP.** [Introduction](https://owasp.org/Top10/2025/0x00_2025-Introduction/). La metodología, la cantidad de CWE revisadas, el reparto entre datos y encuesta, y los cambios respecto de 2021.
3. **OWASP.** [A01:2025 Broken Access Control](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/). La categoría con más detalle y ejemplos.
4. **OWASP.** [A03:2025 Software Supply Chain Failures](https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/). La categoría nueva que subió al tercer puesto.
5. **MITRE.** [Common Weakness Enumeration (CWE)](https://cwe.mitre.org/). El catálogo de debilidades sobre el que se construye la lista.

## Guías relacionadas

- [Qué es OWASP](../que-es-owasp/index.md)
- [Cadena de suministro](../ataques-de-cadena-de-suministro/index.md)
- [Fundamentos de hacking ético](../fundamentos-hacking-etico/index.md)
- [SSL y HTTPS](../../desarrollo-web/ssl-tls-certificados-y-https/index.md)
- [Índice de Hacking ético](../index.md)