OWASP Top 10 en 2025: las vulnerabilidades web más críticas y cómo prevenirlas

OWASP Top 10: la referencia de seguridad web

El OWASP Top 10 es la lista de referencia de las vulnerabilidades de seguridad web más críticas, mantenida por la Open Web Application Security Project. Es el estándar de facto que utilizan auditorías de seguridad, certificaciones y normativas como PCI DSS. Conocerlo no es opcional para cualquier equipo de desarrollo profesional.

La octava edición de la lista, el OWASP Top 10:2025, se presentó en noviembre de 2025 en la Global AppSec de Washington y se publicó en versión definitiva a comienzos de 2026. Es la edición construida sobre el mayor volumen de datos hasta la fecha: información de más de 2,8 millones de aplicaciones aportada por trece organizaciones (Veracode, Sonar, Semgrep, Contrast Security, Bugcrowd, Orca Security y otras), y un análisis de 589 CWEs de los que 248 acabaron repartidos entre las diez categorías finales.

Si vienes de la edición de 2021, hay cambios que afectan directamente a cómo priorizas el trabajo: dos categorías nuevas, una consolidación y un reordenamiento importante en la mitad alta de la tabla. Este artículo repasa las diez categorías con ejemplos concretos, qué mirar en tu propio código y cómo montar un plan de adopción realista que no bloquee el roadmap de producto.

Qué cambió en la edición 2025 respecto a 2021

La metodología del Top 10 sigue siendo data-informed, no data-driven: ocho categorías salen directamente de los datos de testing y dos las promueve la encuesta a la comunidad. El motivo es sencillo: los datos automatizados solo reflejan lo que las herramientas ya saben detectar, y siempre miran hacia atrás. La encuesta compensa ese sesgo con lo que los equipos de AppSec están viendo hoy sobre el terreno.

Los tres cambios estructurales de esta edición son:

• Software Supply Chain Failures (A03) es nueva. Amplía la antigua categoría de componentes vulnerables y desactualizados para cubrir todo el ecosistema: dependencias, sistemas de build e infraestructura de distribución. Fue la categoría más votada por la comunidad.
• Mishandling of Exceptional Conditions (A10) es nueva. Agrupa 24 CWEs sobre gestión incorrecta de errores, errores lógicos y sistemas que fallan abiertos ante condiciones anómalas.
• SSRF desaparece como categoría propia y se integra dentro de Broken Access Control, donde conceptualmente encaja mejor.

Además, Security Misconfiguration da un salto del puesto 5 al 2, mientras que Cryptographic Failures e Injection bajan dos posiciones cada una. No es que cifrado e inyección hayan dejado de importar: es que la superficie de configuración de las aplicaciones modernas ha crecido muchísimo y los fallos se han vuelto más prevalentes ahí.

A01:2025 — Broken Access Control

La vulnerabilidad número uno, otra vez. Ocurre cuando un usuario puede acceder a recursos o realizar acciones que no debería: ver datos de otros usuarios, modificar permisos, acceder a funciones de administrador. En los datos de esta edición, un 3,73% de las aplicaciones analizadas presentaba al menos uno de los 40 CWEs de la categoría, la más numerosa de las diez.

La novedad de 2025 es que SSRF (Server-Side Request Forgery) se ha absorbido aquí. Tiene lógica: cuando un servidor hace peticiones a URLs controladas por el usuario, lo que falla de fondo es la validación de a qué recursos se permite llegar.

Cómo se manifiesta en la práctica

• IDOR: cambiar /api/pedidos/1042 por /api/pedidos/1043 y ver el pedido de otro cliente.
• Escalada horizontal y vertical: un usuario estándar que alcanza endpoints de administración porque el control solo se aplicaba ocultando el botón en el frontend.
• CORS mal configurado que permite leer respuestas autenticadas desde orígenes arbitrarios.
• SSRF: un campo de importación por URL que acaba consultando el servicio de metadatos interno del cloud.

Prevención

Implementa controles de acceso en el backend (nunca solo en el frontend), aplica el principio de mínimo privilegio, y verifica permisos en cada endpoint, no en el router ni en el middleware genérico. Deniega por defecto: cualquier recurso nuevo debe ser inaccesible hasta que alguien declare explícitamente quién puede tocarlo. Y registra los fallos de autorización, porque son la señal temprana de que alguien está probando. Si trabajas con APIs expuestas a terceros, este control es el que más rendimiento da: lo desarrollamos en profundidad en nuestra guía sobre seguridad de APIs empresariales.

A02:2025 — Security Misconfiguration

Sube del puesto 5 al 2. Un 3,00% de las aplicaciones analizadas tenía al menos uno de los 16 CWEs de esta categoría. El motivo del ascenso es estructural: cada vez más comportamiento de una aplicación depende de configuración —contenedores, orquestadores, buckets, gateways, feature flags— y cada capa nueva es una superficie más donde equivocarse.

Configuraciones por defecto inseguras: headers de seguridad ausentes, páginas de error con stack traces, servicios innecesarios expuestos, credenciales por defecto, directorio de uploads accesible públicamente, buckets de almacenamiento abiertos, paneles de administración accesibles desde Internet sin restricción de red.

Prevención

Mantén un checklist de configuración de seguridad y revísalo en cada despliegue. Automatiza lo que puedas: plantillas de infraestructura como código revisadas, imágenes base endurecidas, y un escaneo de configuración en el pipeline. Los cuatro headers que deberías tener siempre son Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options y Referrer-Policy. En entornos WordPress y ecommerce, la mayor parte de los incidentes que vemos empiezan aquí: un panel expuesto, un plugin con configuración por defecto o un backup accesible por URL. Lo contamos con casos reales en el análisis de la vulnerabilidad WP2Shell.

A03:2025 — Software Supply Chain Failures

La gran novedad de esta edición y la categoría más votada por la comunidad. Amplía la antigua Vulnerable and Outdated Components para cubrir todo el ciclo: las dependencias que instalas, el sistema de build que las empaqueta y la infraestructura que las distribuye.

Solo tiene 5 CWEs asociados y una presencia limitada en los datos —es difícil de testear de forma automatizada—, pero es la categoría con las puntuaciones medias de explotabilidad e impacto más altas de todos los CVEs analizados. Dicho de otro modo: pasa poco en los escaneos, pero cuando pasa duele mucho.

Qué vigilar

• Dependencias directas y transitivas sin actualizar o abandonadas por sus mantenedores.
• Typosquatting en npm, PyPI o Packagist: paquetes con nombres casi idénticos al legítimo.
• Compromiso del pipeline: tokens de CI con permisos excesivos, acciones de terceros ancladas a una rama en vez de a un commit.
• Artefactos sin firmar y registries internos sin control de procedencia.

Prevención

Genera un SBOM (inventario de materiales de software) por cada release y consérvalo: cuando salga el próximo CVE crítico en una librería popular, la diferencia entre responder en una hora o en tres días es tener ese inventario. Fija versiones con lockfiles, ancla las acciones de CI a hashes concretos, revisa qué permisos tiene cada token del pipeline y automatiza el escaneo de composición (SCA) en cada pull request.

A04:2025 — Cryptographic Failures

Baja del puesto 2 al 4, aunque sigue siendo muy prevalente: un 3,80% de las aplicaciones tenía al menos uno de sus 32 CWEs. Datos sensibles transmitidos o almacenados sin cifrado adecuado. Incluye: HTTP en lugar de HTTPS, contraseñas hasheadas con MD5 o SHA1 (usar bcrypt, scrypt o Argon2), datos personales sin cifrar en la base de datos, y cookies de sesión sin flags Secure y HttpOnly.

En 2026 hay que añadir dos frentes más. El primero, la gestión de secretos: claves y tokens en el repositorio siguen siendo una de las causas más habituales de incidente. El segundo, la criptografía post-cuántica: no es urgente para la mayoría de aplicaciones de negocio, pero si manejas datos que deben seguir siendo confidenciales dentro de diez o quince años, conviene empezar a inventariar dónde usas RSA y curvas elípticas.

Prevención

Clasifica primero qué datos tratas y qué exige la normativa para cada tipo. Aplica TLS en todas partes, incluido el tráfico entre servicios internos. Usa algoritmos y modos actuales (AES-GCM, ChaCha20-Poly1305) y bibliotecas mantenidas en vez de implementaciones propias. Y rota claves con un procedimiento probado: una clave que no se sabe rotar es una clave comprometida en potencia.

A05:2025 — Injection

SQL Injection, NoSQL Injection, Command Injection siguen siendo un problema real. Baja del puesto 3 al 5, pero es la categoría más testeada y la que acumula el mayor número de CVEs de los 38 CWEs que agrupa. Cubre desde Cross-Site Scripting (alta frecuencia, impacto bajo) hasta SQL Injection (baja frecuencia, impacto alto).

La prevención es simple pero requiere disciplina: usa siempre consultas parametrizadas (prepared statements), nunca concatenes input del usuario en consultas, valida y sanitiza toda entrada, y usa ORMs correctamente configurados. Ojo con los métodos de raw query de los ORMs: son la vía por la que la inyección vuelve a colarse en bases de código que se creían a salvo.

// MAL: concatenación directa
$sql = "SELECT * FROM pedidos WHERE cliente = '" . $_GET['id'] . "'";

// BIEN: consulta parametrizada
$stmt = $pdo->prepare('SELECT * FROM pedidos WHERE cliente = :id');
$stmt->execute(['id' => $_GET['id']]);

Para XSS, la defensa moderna combina escapado contextual en plantillas, Content-Security-Policy restrictiva y evitar por completo construcciones tipo innerHTML con datos de usuario. Añade a la lista la inyección de prompts si tu aplicación integra modelos de lenguaje: el patrón de fondo —mezclar instrucciones y datos no confiables en el mismo canal— es exactamente el mismo.

A06:2025 — Insecure Design

Cae del 4 al 6, y OWASP lo interpreta como buena noticia: el threat modeling y el diseño seguro se han extendido en la industria desde que la categoría se introdujo en 2021. Aquí no hablamos de un bug concreto, sino de decisiones de arquitectura que hacen imposible ser seguro por mucho que el código esté bien escrito: un flujo de recuperación de contraseña basado en preguntas personales, un carrito que confía en el precio que envía el cliente, o un límite de intentos que solo existe en la interfaz.

La forma de atacarlo es hacer modelado de amenazas en la fase de diseño, definir requisitos de seguridad junto a los funcionales y establecer patrones reutilizables (autenticación, autorización, gestión de sesiones) que los equipos apliquen por defecto en vez de reinventar en cada proyecto.

A07:2025 — Authentication Failures

Mantiene el puesto 7 con un cambio de nombre —antes Identification and Authentication Failures— que refleja mejor los 36 CWEs que agrupa. Que no haya subido tiene una explicación positiva: el uso de frameworks estandarizados de autenticación está reduciendo la frecuencia de estos fallos.

Los patrones que siguen apareciendo en auditoría: ausencia de límite de intentos, sesiones que no se invalidan al cambiar la contraseña, tokens de recuperación predecibles o de larga duración, y MFA implementado solo en el login pero no en las operaciones sensibles. Apóyate en soluciones probadas (OIDC, proveedores de identidad) antes que en implementaciones propias, obliga a MFA en cuentas con privilegios y comprueba las contraseñas contra listas de credenciales filtradas.

A08:2025 — Software or Data Integrity Failures

Continúa en el puesto 8. Se centra en el fallo al mantener las fronteras de confianza y verificar la integridad del software, el código y los artefactos de datos, a un nivel más bajo que la cadena de suministro de A03. Los casos típicos son la deserialización insegura, las actualizaciones automáticas sin verificación de firma y los pipelines que despliegan artefactos que nadie ha validado.

Firma tus artefactos, verifica las firmas antes de desplegar, evita deserializar datos de origen no confiable y, si no queda más remedio, restringe explícitamente las clases permitidas.

A09:2025 — Security Logging & Alerting Failures

Retiene el puesto 9 y cambia de nombre —antes Logging and Monitoring— para subrayar la parte de alerta. El matiz importa: un logging excelente sin alertas que provoquen una acción no sirve de nada para detectar un incidente. Es una categoría que siempre estará infrarrepresentada en los datos automatizados y que, de nuevo, entró en la lista por votación de la comunidad.

Lo mínimo razonable: registrar intentos de login fallidos, fallos de control de acceso y errores de validación con contexto suficiente para investigar; centralizar los logs fuera del servidor que los genera; definir alertas sobre patrones concretos y no sobre volumen; y no registrar nunca contraseñas, tokens ni datos personales innecesarios. Después, probar de verdad que la alerta llega a alguien que sabe qué hacer con ella.

A10:2025 — Mishandling of Exceptional Conditions

La segunda categoría nueva de 2025, con 24 CWEs sobre gestión incorrecta de errores, errores lógicos y sistemas que fallan abriendo en vez de cerrando. Ejemplos que probablemente reconozcas: un bloque catch vacío que se traga la excepción y deja el flujo continuar; una comprobación de licencia o de permisos que, si el servicio externo no responde, decide dejar pasar; un mensaje de error que revela la estructura interna de la base de datos.

La regla general es fail closed: ante una condición inesperada, denegar. Devuelve mensajes de error genéricos al usuario y guarda el detalle en el log. Y trata las rutas de error como código de primera clase, con sus propios tests: son las que menos se prueban y las que más se explotan.

Implementación práctica: hoja de ruta en 90 días

No intentes abordar todo a la vez. Empieza por las vulnerabilidades más impactantes para tu aplicación (normalmente Broken Access Control e Injection), implementa testing de seguridad automatizado en tu pipeline CI/CD (herramientas como OWASP ZAP o Snyk), y programa auditorías periódicas. La seguridad es un proceso continuo, no un proyecto con fecha de fin. Cuando necesitas apoyo externo, en Keliam integramos esta prevención dentro de nuestros servicios de seguridad informática.

Un plan de 90 días que hemos visto funcionar en equipos de producto pequeños y medianos:

Días 1-30: inventario y visibilidad

No puedes proteger lo que no sabes que tienes. Genera el SBOM de cada aplicación, lista los endpoints expuestos con sus roles asociados, identifica dónde viven los datos personales y lanza un primer escaneo SCA y SAST para tener una línea base. El objetivo de este mes no es arreglar nada, es saber de qué tamaño es el problema.

Días 31-60: controles críticos

Ataca lo que más riesgo concentra: revisar que todo control de acceso esté en el backend, sacar los secretos del repositorio hacia un gestor, aplicar headers de seguridad y hardening de configuración, y activar MFA en las cuentas privilegiadas. Son cambios acotados, con impacto alto y poco riesgo de regresión.

Días 61-90: automatizar y medir

Lo que no se automatiza se abandona. Integra DAST en el pipeline, define alertas reales sobre los eventos de seguridad, revisa las rutas de error y cierra el ciclo con un pentest externo. A partir de aquí, mide: número de hallazgos abiertos por severidad, tiempo medio de corrección y porcentaje de builds que pasan los controles.

Herramientas para automatizar el Top 10

Ninguna herramienta cubre las diez categorías, y desconfía de la que diga lo contrario. Una combinación razonable y sostenible:

• SCA (Dependabot, Snyk, OWASP Dependency-Check) para A03 y A06: dependencias y componentes.
• SAST (Semgrep, SonarQube, CodeQL) para A05 e A01: inyección y patrones de autorización.
• DAST (OWASP ZAP, Burp Suite) para A01, A02 y A05 en tiempo de ejecución.
• Escaneo de secretos (gitleaks, trufflehog) para A04.
• Escaneo de configuración e IaC (Trivy, Checkov) para A02.
• Revisión manual y pentest para A06, A08 y A10: el diseño inseguro y los errores lógicos no los detecta ninguna herramienta automática.

El error clásico es enchufar cinco escáneres, generar 4.000 hallazgos y perder la confianza del equipo de desarrollo en dos semanas. Arranca con un escáner por categoría, con el umbral puesto solo en severidad alta, y ve bajando el listón a medida que la deuda se reduce.

OWASP Top 10, ISO 27001 y ENS: cómo encajan

El Top 10 es una lista de riesgos técnicos, no un marco de gestión. Su valor dentro de una certificación es servir de evidencia concreta de que el control de desarrollo seguro existe y se aplica. Si tu equipo trabaja contra el OWASP Top 10 de forma sistemática, ya tiene medio camino hecho para el control de codificación segura de la ISO 27001 — lo contamos en nuestra guía de controles técnicos y desarrollo seguro, dentro de la guía completa de certificación ISO 27001.

En el ámbito público pasa algo parecido: el Esquema Nacional de Seguridad exige medidas de protección de las aplicaciones que se sostienen precisamente sobre este tipo de prácticas. Y si tu empresa entra en el ámbito de NIS2, la gestión de la cadena de suministro de A03 deja de ser una buena práctica para convertirse en una obligación regulatoria.

Errores frecuentes al adoptar el Top 10

• Tratarlo como un checklist de auditoría en vez de como un modelo de riesgos. El Top 10 es un punto de partida, no una certificación de que la aplicación es segura.
• Delegarlo todo en herramientas. Insecure Design y Mishandling of Exceptional Conditions requieren criterio humano.
• Empezar por el final. Montar un SIEM antes de tener los controles de acceso en orden es invertir en detectar lo que se podría haber evitado.
• Ignorar el entorno de desarrollo. Los pipelines y los entornos de staging son objetivos legítimos y suelen estar peor protegidos que producción.
• No medir. Sin métricas de hallazgos y tiempos de corrección, el esfuerzo se diluye en cuanto llega la siguiente entrega urgente.

Si estás empezando de cero y no sabes por dónde tirar, nuestra guía de ciberseguridad para empresas y la de seguridad informática para pymes ordenan los primeros pasos antes de entrar en el detalle técnico.

Conclusión

El OWASP Top 10:2025 confirma dos tendencias que llevan años asomando. La primera: el control de acceso sigue siendo el punto más débil de las aplicaciones web, edición tras edición. La segunda: el riesgo se ha desplazado hacia lo que rodea al código —la configuración y la cadena de suministro— más que hacia el código en sí.

Para un equipo de desarrollo, eso se traduce en algo bastante concreto: revisa la autorización endpoint por endpoint, endurece la configuración de cada entorno y sé capaz de responder en minutos a la pregunta de qué dependencias usas y en qué versión. Con eso cubierto, las siete categorías restantes se vuelven mucho más manejables.

Y recuerda que ninguna edición del Top 10 sustituye a mirar tu propio contexto: una aplicación de banca, un ecommerce y una API interna tienen perfiles de riesgo distintos. Si quieres una foto real de dónde está tu aplicación, una auditoría de seguridad con pentesting es la forma más rápida de saberlo.