La mayoría de los problemas de seguridad no ocurren por fallos sofisticados, sino por errores conocidos que se repiten una y otra vez. Cada pocos años, la fundación Open Worldwide Application Security Project (OWASP) elabora un informe donde analiza los tipos de vulnerabilidades en apps más comunes.
Con el auge de tendencias como el vibecoding o la programación mediante agentes, donde gracias a las capacidades de IA se crea software de forma más desatendida, es interesante conocer qué mecanismos pueden permitir evitar brechas de seguridad, robos de datos o suplantación de identidad.
La nueva edición del Top 10 de OWASP de 2025 trae consigo ciertas novedades respecto a la anterior publicada en 2021. Vamos a desglosar cada una de ellas.
Qué vas as ver en esta entrada
1. Control de acceso deficiente
Al igual que en 2021, este tipo de vulnerabilidades es el más frecuente y el que más dolores de cabeza causa. Está presente en el 100% de las aplicaciones analizadas.
Los problemas de control de acceso en una aplicación se refieren, por ejemplo, a no aplicar el principio de mínimo privilegio que permiten a un usuario actuar fuera de sus permisos previstos.
Los vectores más comunes incluyen: manipulación de parámetros en URLs o cabeceras HTTP, referencias directas a objetos inseguros (un usuario accede a /api/orders/123, pero cambia la URL a /api/orders/124 y ve el pedido de otro usuario). También se puede incluir la ausencia de controles de acceso en endpoints POST/PUT/DELETE, o una mala configuración de elementos de control de estado o autenticación como CSRF y CORS.
La principal mitigación para este tipo de problemas es recordar que el control de acceso solo es efectivo cuando se implementa en código del lado del servidor de confianza, nunca en el cliente.
2. Malas configuraciones de seguridad
Sube del puesto 5 al segundo lugar, también está presente en el 100% de las aplicaciones analizadas.
Un sistema es vulnerable cuando cualquier capa de su stack (servidor, framework, base de datos, cloud) no está correctamente asegurada.
Los escenarios más frecuentes: aplicaciones o consolas de administración con credenciales por defecto en producción, mensajes de error que exponen trazas del stack, versiones de componentes, permisos excesivos en buckets S3 o similares, y ausencia de cabeceras de seguridad.
A mayor complejidad de software e infraestructura (contenedores, despliegues en cloud, microservicios), mayor superficie de error. Es necesario tener procesos de hardening en todos los niveles para mitigar riesgos.
3. Fallos en la cadena de suministro del software
La más votada por la comunidad como principal riesgo. Sube desde la sexta posición en 2021.
Extiende la categoría anterior de «componentes vulnerables» para cubrir todo el ciclo de construcción y distribución: dependencias transitivas sin auditar, pipelines CI/CD con controles de seguridad más débiles que los sistemas que despliegan, componentes de fuentes no confiables, y ausencia de separación de responsabilidades en el flujo de promoción a producción.
Los casos de referencia incluidos en 2025 muestran su alcance real: el robo de 1.500 millones de dólares a la plataforma de criptomonedas Bybit mediante un ataque a su software de wallets que solo se activaba bajo condiciones específicas, o el gusano npm Shai-Hulud, que comprometió más de 500 versiones de paquetes exfiltrando tokens de la plataforma npm para continuar su propagación.
La mitigación principal pasa por generar y mantener un Software Bill of Materials (SBOM) completo, incluyendo dependencias transitivas. Otra forma de limitar riesgos pasa por aplicar staged rollouts o despliegues por etapas para limitar la exposición ante una vulnerabilidad en alguno de los componentes de la aplicación.
4. Fallos Criptográficos
Otra conocida del ranking, en esta ocasión baja dos posiciones en su edición de 2021 y ocupa el cuarto puesto.
Abarca el uso de algoritmos débiles, rotos o mal implementados (MD5, SHA1, CBC), generadores de números pseudoaleatorios que no se consideran seguros a nivel criptográfico, claves hardcodeadas o presentes en algún commit el en historial del repositorio, ausencia de cifrado para datos sensibles, y gestión deficiente del ciclo de vida de claves.
OWASP añade en esta edición una advertencia explícita: es necesario comenzar ahora la transición a criptografía post-cuántica (PQC). Los sistemas de alto riesgo deben estar protegidos frente a computación cuántica antes de finales de 2030, siguiendo las recomendaciones de ENISA.
Para contraseñas, los algoritmos recomendados son Argon2, yescrypt, scrypt o PBKDF2-HMAC-SHA-512.
5. Inyecciones
Baja un poco en el ranking, del tercer al quinto puesto. En esta categoría se encuentran más de 62.000 CVEs (Common Vulnerability and Exposure), la mayor de todo el Top 10.
Dentro de los vectores de ataque en este tipo de vulnerabilidades podemos encontrar: inputs sin validar, filtrar o sanitizar que llegan a un intérprete (base de datos, sistema operativo, navegador) y se ejecutan como parte de un comando. Esto aplica a inyecciones SQL, NoSQL, comandos de sistemas operativos o XSS.
Una solución para evitar diversos tipos de inyecciones es utilizar APIs parametrizadas o ORMs. Si no es posible, aplicar validación positiva en el lado del servidor y un escapado específico del intérprete.
Como nota adicional, OWASP referencia en esta edición el Prompt Injection como clase relacionada, remitiéndolo al LLM Top 10.
6. Diseño inseguro
Esta categoría baja en la edición de 2025 del cuarto al sexto puesto.
OWASP distingue explícitamente entre diseño inseguro e implementación insegura: son problemas con distintas casuísticas, que ocurren en fases distintas del ciclo de desarrollo y requieren remediaciones concretas. Una implementación correcta no puede compensar controles de seguridad que nunca fueron diseñados.
Esta categoría abarca fallos en la lógica de negocio, ausencia de threat modeling, y falta de segregación de tenants o capas.
La mitigación requiere aplicar medidas de seguridad antes del código: desde la toma de requisitos, en el diseño de flujos de usuario y en la definición de casos de abuso, no solo en la revisión de código.
7. Fallos de autenticación
Al igual que en la edición de 2021, esta categoría se mantiene en séptima posición.
Los fallos de autenticación son debilidades en la verificación de identidad que permiten a un atacante hacerse pasar por un usuario legítimo. Los vectores incluyen ausencia de MFA, credenciales hardcodeadas, permisos de contraseñas débiles, sesiones no invalidadas correctamente tras un cierre de sesión, y flujos de recuperación inseguros (las típicas «preguntas secretas» están explícitamente prohibidas por NIST 800-63b).
En 2025, OWASP refleja el auge de los hybrid credential stuffing attacks: un atacante no solo usa credenciales filtradas, sino que genera variantes incrementales (por ejemplo, rotar una contraseña Winter2025 a Winter2026) basándose en patrones predecibles.
La recomendación para evitar este tipo de riesgos es implementar validación contra listas de credenciales comprometidas (para ello hay portales como Have I Been Pwned) tanto en el registro como en el cambio de contraseña.
8. Fallos de integridad de datos o de software
También se mantiene en el mismo puesto que en 2021.
Se asemeja en concepto a los fallos en la cadena de suministro de software mencionados anteriormente, pero opera en una capa más baja. Esta categoría refleja aquellos fallos que se dan cuando el artefacto que ejecutas no es íntegro. Cubre plugins o librerías cargadas desde fuentes no verificadas, actualizaciones automáticas sin validación de firma digital o pipelines CI/CD sin controles de integridad.
La mitigación incluiría firmas digitales en artefactos, así como el uso de repositorios internos para dependencias de alto riesgo.
9. Fallos en el alertado y registros de seguridad
Con un cambio de nombre para mayor énfasis en la parte de alertado, esta categoría mantiene su noveno puesto en el ranking.
Esta categoría es difícil de medir estadísticamente (solo 723 CVEs asociados), pero su impacto operativo es crítico. Los fallos típicos: no registrar eventos auditables (logins fallidos, accesos denegados…), registros sin protección contra manipulación, ausencia de umbrales de alerta, y falsos positivos que saturan al equipo SOC impidiendo detectar amenazas reales.
Uno de los escenarios documentados describe una brecha de más de 7 años sin detectar por ausencia de monitorización. OWASP recomienda el uso de honeytokens como mecanismo de detección.
10. Mal manejo de condiciones excepcionales
Para finalizar este ranking contamos con una categoría nueva. Cuenta con 24 CWEs (Common Weakness Enumeration) y tiene una tasa máxima de incidencia del 20,67%.
Cuando una aplicación no previene, detecta o responde adecuadamente a condiciones excepcionales, el resultado puede ir desde exponer información sensible en mensajes de error hasta corromper el estado en transacciones financieras, pasando por denegación de servicio por recursos no liberados.
El principio fundamental es fail closed: ante cualquier error durante una transacción, el sistema debe hacer rollback completo antes de informar del fallo. Intentar recuperar una transacción parcialmente completada es donde se generan vulnerabilidades difíciles de reproducir y detectar.
La mitigación requiere manejo de excepciones en el punto donde ocurren (no en capas superiores), un handler global como red de seguridad, rate limiting en todos los flujos susceptibles, y centralización del logging y alerting de errores.
Conclusión
El OWASP Top 10 2025 refleja una madurez en cómo la industria entiende los riesgos: de vulnerabilidades y bugs aislados de implementación a fallos sistémicos que abarcan el diseño, la cadena de suministro y la propia operativa. Conocerlos es el primer paso para no reproducirlos, independientemente de si el código se ha generado de forma artesanal o a través de inteligencia artificial.
