OWASP Top 10 2025: Vulnerabilidades Web Explicadas con Ejemplos

¿Cuántas aplicaciones hacen falta para saber qué falla en la seguridad web? Para su edición más reciente, OWASP analizó datos de más de 2,8 millones de aplicaciones. El resultado confirma algo incómodo: los errores que más se repiten no son ataques sofisticados, sino descuidos de diseño y configuración.

La buena noticia es que casi todos se pueden prevenir si sabes dónde mirar.

En esta guía tienes las 10 categorías de vulnerabilidades del OWASP Top 10 2025 explicadas con ejemplos de código, qué cambió respecto a la lista de 2021 y una checklist para revisar tu próximo proyecto.

---

¿Qué Es el OWASP Top 10 y Para Qué Sirve?

OWASP (Open Worldwide Application Security Project) es una fundación sin fines de lucro que publica guías, herramientas y estándares abiertos de seguridad de software. Su proyecto más conocido es el Top 10: un documento de concienciación con los riesgos más críticos de las aplicaciones web.

La edición 2025 es la octava. Agrupa 248 debilidades (CWE) en 10 categorías. Ocho de ellas salen de datos aportados por empresas y analistas, y dos de una encuesta a la comunidad de seguridad, para captar riesgos nuevos que los datos todavía no reflejan.

Importante: el Top 10 es un punto de partida, no una certificación. Si necesitas verificar a fondo una aplicación, OWASP recomienda su estándar ASVS (Application Security Verification Standard), mucho más detallado.

¿Qué Cambió del OWASP Top 10 2021 al 2025?

Hay dos categorías nuevas, una fusión y varios cambios de posición:

Posición 2025	Categoría	En 2021
A01	Control de acceso roto	#1 (ahora incluye SSRF, que era #10)
A02	Configuración de seguridad incorrecta	#5
A03	Fallos en la cadena de suministro de software	Nueva (amplía “Componentes vulnerables”, #6)
A04	Fallos criptográficos	#2
A05	Inyección	#3
A06	Diseño inseguro	#4
A07	Fallos de autenticación	#7 (renombrada)
A08	Fallos de integridad de software o datos	#8
A09	Fallos de registro y alertas de seguridad	#9 (renombrada)
A10	Manejo incorrecto de condiciones excepcionales	Nueva

---

Las 10 Categorías del OWASP Top 10 2025 Explicadas

A01: Control de Acceso Roto (Ahora Incluye SSRF)

Sigue en el primer lugar. Ocurre cuando un usuario puede ver o modificar datos que no le corresponden. El caso clásico es el IDOR: cambiar un número en la URL y acceder a la cuenta de otra persona.

// ❌ Vulnerable: cualquiera con sesión puede leer cualquier factura
app.get('/api/facturas/:id', requireLogin, async (req, res) => {
  const factura = await db.facturas.findById(req.params.id);
  res.json(factura);
});

// ✅ Seguro: el servidor comprueba que la factura pertenece al usuario
app.get('/api/facturas/:id', requireLogin, async (req, res) => {
  const factura = await db.facturas.findOne({ id: req.params.id, userId: req.user.id });
  if (!factura) return res.status(404).end();
  res.json(factura);
});

En 2025 esta categoría absorbe SSRF (Server-Side Request Forgery): cuando tu servidor descarga una URL que eligió el atacante y termina accediendo a servicios internos. La defensa es validar las URLs contra una lista de destinos permitidos.

A02: Configuración de Seguridad Incorrecta

Es la que más sube entre las categorías que ya existían: de #5 a #2. Incluye contraseñas por defecto sin cambiar, modo debug activo en producción, buckets en la nube abiertos al público y cabeceras de seguridad ausentes.

Estas cabeceras HTTP son un buen punto de partida:

Content-Security-Policy: default-src 'self'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin

Ajusta la Content-Security-Policy a tu sitio: si usas scripts de terceros, tendrás que permitir esos dominios de forma explícita.

A03: Fallos en la Cadena de Suministro de Software

Esta categoría es nueva y amplía la antigua “componentes vulnerables y desactualizados”. Ya no se trata solo de librerías con fallos conocidos, sino de todo lo que entra en tu software: dependencias, herramientas de compilación, pipelines de CI/CD y hasta las extensiones de tu editor.

El caso de xz Utils en 2024 lo ilustra bien: alguien se ganó durante años la confianza del proyecto y terminó insertando una puerta trasera (CVE-2024-3094) en una librería presente en muchas distribuciones de Linux. Se descubrió casi por casualidad, antes de llegar a las versiones estables de la mayoría.

Medidas concretas:

• Ejecuta npm audit (o el equivalente de tu lenguaje) y activa Dependabot o Renovate.
• Usa archivos de bloqueo (package-lock.json) y revisa qué cambia al actualizar.
• Instala solo dependencias que de verdad necesitas y comprueba que estén mantenidas.
• Genera un SBOM (lista de componentes) en proyectos profesionales.

A04: Fallos Criptográficos

Baja al cuarto lugar, pero sigue siendo grave: datos sensibles sin cifrar, algoritmos obsoletos o claves mal gestionadas.

• Usa HTTPS en todo el sitio, no solo en el login.
• Guarda contraseñas con funciones diseñadas para eso, como Argon2id o bcrypt. Nunca uses MD5 ni SHA-1, ni guardes contraseñas cifradas de forma reversible.
• No incluyas claves ni secretos en el código fuente; usa variables de entorno o un gestor de secretos.

A05: Inyección (SQL, XSS y Comandos)

La inyección ocurre cuando datos del usuario se interpretan como código. Desde 2021 incluye también el XSS (Cross-Site Scripting).

// ❌ Vulnerable: el texto del usuario se pega dentro de la consulta SQL
const sql = `SELECT * FROM usuarios WHERE email = '${email}'`;

// ✅ Seguro: consulta parametrizada; la base de datos trata el valor como dato
const { rows } = await pool.query('SELECT * FROM usuarios WHERE email = $1', [email]);

Para el XSS, la regla es la misma: escapa la salida. Los frameworks modernos como React, Vue o Astro lo hacen por defecto; el peligro aparece cuando insertas HTML “en crudo” con funciones como innerHTML o v-html.

A06: Diseño Inseguro

Agrupa fallos que nacen en la planificación, no en el código. Una implementación perfecta de un diseño inseguro sigue siendo insegura.

Un ejemplo: una función de “recuperar contraseña” que envía un código de 4 dígitos sin limitar los intentos. El código puede estar impecable, pero un atacante prueba las 10.000 combinaciones en minutos. La defensa es el modelado de amenazas: preguntarte “¿cómo abusaría alguien de esto?” antes de programar.

A07: Fallos de Autenticación

Se refiere a todo lo que permite suplantar a un usuario: contraseñas débiles, ausencia de doble factor, sesiones que no expiran o ataques de credential stuffing (probar contraseñas filtradas de otros sitios).

• Ofrece autenticación multifactor (MFA), al menos para cuentas con privilegios.
• Limita los intentos de inicio de sesión por cuenta y por IP.
• Invalida la sesión en el servidor al cerrar sesión y al cambiar la contraseña.
• Rechaza contraseñas que aparecen en filtraciones conocidas.

A08: Fallos de Integridad de Software o Datos

Ocurre cuando confías en código o datos sin verificar que no fueron alterados: actualizaciones sin firma, deserialización de datos no confiables o scripts cargados desde un CDN que alguien podría modificar.

Si cargas una librería desde un CDN, el atributo integrity (Subresource Integrity) hace que el navegador la bloquee si su contenido cambia:

<script
  src="https://cdn.ejemplo.com/libreria.min.js"
  integrity="sha384-HASH_PUBLICADO_POR_LA_LIBRERIA"
  crossorigin="anonymous"></script>

A09: Fallos de Registro y Alertas de Seguridad

Cambió de nombre para recalcar las alertas: guardar logs no sirve de nada si nadie se entera cuando algo va mal.

• Registra inicios de sesión fallidos, cambios de permisos y errores de validación en el servidor.
• Configura alertas para patrones anómalos, como cientos de logins fallidos en un minuto.
• Nunca guardes contraseñas, tokens ni datos de tarjetas en los logs.

A10: Manejo Incorrecto de Condiciones Excepcionales

Es la otra categoría nueva. Cubre lo que pasa cuando algo sale mal: errores no controlados, mensajes que revelan detalles internos y, sobre todo, sistemas que “fallan abiertos”.

// ❌ Falla abierto: si el servicio de permisos se cae, todos son administradores
async function esAdmin(usuario) {
  try {
    return await servicioPermisos.verificar(usuario, 'admin');
  } catch {
    return true;
  }
}

// ✅ Falla cerrado: ante la duda, se niega el acceso y se registra el error
async function esAdmin(usuario) {
  try {
    return await servicioPermisos.verificar(usuario, 'admin');
  } catch (error) {
    logger.error('Fallo al verificar permisos', { usuario: usuario.id, error });
    return false;
  }
}

Muestra al usuario mensajes de error genéricos y deja el detalle técnico, como los stack traces, solo en tus logs.

---

Checklist de Seguridad OWASP para Tu Próximo Proyecto

Antes de publicar una aplicación, repasa esta lista:

1. ¿Cada endpoint comprueba en el servidor que el usuario tiene permiso sobre ese recurso?
2. ¿Están desactivados el modo debug y las cuentas por defecto en producción?
3. ¿Revisaste las dependencias con npm audit o una herramienta equivalente?
4. ¿Las contraseñas se guardan con Argon2id o bcrypt, y todo el sitio usa HTTPS?
5. ¿Todas las consultas a la base de datos están parametrizadas?
6. ¿Hay límite de intentos en el login y en la recuperación de contraseña?
7. ¿Los errores fallan “cerrados” y sin mostrar detalles internos?

Un detalle que conecta con el control de versiones: muchas filtraciones empiezan con una clave de API subida por error a un repositorio. Si estás empezando con Git, revisa en nuestro tutorial de Git desde cero cómo usar .gitignore para evitarlo.

---

Límites del OWASP Top 10 que Debes Tener en Cuenta

Usar el Top 10 como única referencia de seguridad es un error común. Ten presentes sus límites:

• No es exhaustivo. Diez categorías no cubren todas las debilidades posibles. Para auditorías completas usa el ASVS.
• Refleja datos del pasado. Las cifras provienen de pruebas ya realizadas; los riesgos emergentes tardan en aparecer, por eso dos categorías salen de una encuesta.
• Está pensado para aplicaciones web. Para APIs, móviles o modelos de lenguaje, OWASP publica listas específicas, como el API Security Top 10 o el Top 10 para aplicaciones con LLM.
• Las herramientas automáticas no bastan. Un escáner detecta cabeceras ausentes o librerías vulnerables, pero no un fallo de lógica de negocio como el del código de 4 dígitos.

---

La Seguridad Web Empieza en el Diseño, No en el Parche

El OWASP Top 10 2025 deja un mensaje claro: los riesgos que más crecen, como la configuración incorrecta y la cadena de suministro, tienen menos que ver con código brillante y más con disciplina: revisar permisos, dependencias y qué pasa cuando algo falla.

Consulta la lista oficial del OWASP Top 10 2025 para profundizar en cada categoría, y las OWASP Cheat Sheets cuando necesites la solución concreta para tu lenguaje. Si quieres practicar desarrollo web con buenas bases, los cursos gratuitos de freeCodeCamp incluyen proyectos ideales para aplicar esta checklist.

Elige tu proyecto más reciente y pásale la checklist hoy mismo. ¿Cuál de las 10 categorías crees que es la más descuidada en los proyectos de estudiantes? Déjanos tu opinión en los comentarios.