OWASP Top 10 2025: Análisis de Riesgos y Guía de Mitigación

La nueva lista OWASP Top 10 2025 se encuentra actualmente en estado Release Candidate (RC), según el borrador oficial del proyecto, lo que significa que su estructura es estable pero aún puede recibir ajustes menores antes de su publicación final.

El OWASP Top 10 es una lista de referencia que identifica las 10 vulnerabilidades de seguridad más críticas en aplicaciones web. Publicada por la organización sin ánimo de lucro OWASP, esta guía es utilizada por desarrolladores y profesionales de la ciberseguridad para comprender y mitigar los riesgos más comunes y otras vulnerabilidades web importantes.

Ya seas desarrollador, administrador de sistemas, profesional de la ciberseguridad o simplemente estés preocupado por la seguridad de tu sitio web, comprender estas vulnerabilidades es esencial para proteger tus aplicaciones y a tus usuarios.

En esta guía OWASP Top 10 completa, vamos a desglosar cada vulnerabilidad del Top 10 OWASP 2025 (incluyendo fallos de Supply Chain y el impacto de la IA), con ejemplos concretos, técnicas de explotación y, sobre todo, las soluciones para protegerse de ellas.

¿Qué es OWASP y su Proyecto Top 10?

OWASP (Open Web Application Security Project) es una organización mundial sin fines de lucro dedicada a mejorar la seguridad del software. Es una comunidad que publica recursos gratuitos sobre la seguridad de numerosos componentes como IoT, aplicaciones web, inteligencia artificial, API, etc., incluyendo el conocido proyecto Top 10.

Fundada en 2001, OWASP produce:

• Guías y estándares de seguridad gratuitos y de código abierto.
• Herramientas de pruebas de seguridad (OWASP ZAP, Dependency-Check, etc.).
• Proyectos comunitarios (OWASP Top 10, ASVS, SAMM, etc.).
• Formaciones y certificaciones en seguridad de aplicaciones.

¿Por qué es importante el OWASP Top 10?

El Top 10 de OWASP es utilizado por:

• Los desarrolladores para programar de manera segura desde la fase de diseño.
• Los testers de seguridad como referencia para auditar aplicaciones, a menudo como parte de un proceso de pentesting o pruebas de penetración.
• Las empresas para evaluar y priorizar sus inversiones en seguridad.
• Los organismos de certificación (PCI DSS, ISO 27001) como base de cumplimiento.

Comprender y corregir estas 10 vulnerabilidades permite eliminar la mayoría de los riesgos de seguridad en las aplicaciones web.

Cambios Clave: OWASP Top 10 2021 vs. 2025

Cada versión del OWASP Top 10 introduce nuevas temáticas, elimina otras menos relevantes o fusiona categorías. La edición 2025 presenta cambios significativos que reflejan las tendencias actuales, donde cada categoría agrupa diversas debilidades comunes, conocidas como CWE (Common Weakness Enumeration).

Aquí tienes una comparación directa:

A06:2021 (Vulnerable and Outdated Components) ha evolucionado hacia el concepto más amplio de Software Supply Chain Failures. A10:2021 (SSRF) ha sido fusionado en otras categorías, principalmente en Broken Access Control.

Análisis Detallado del OWASP Top 10 2025

Pasemos al detalle del OWASP Top 10 en español.

A01 – Control de Acceso Defectuoso (Broken Access Control)

Descripción

El control de acceso defectuoso ocurre cuando una aplicación no verifica correctamente los permisos de un usuario antes de darle acceso a recursos o funcionalidades.

Ejemplos de ataques

• Escalada de privilegios: un usuario normal accede a funcionalidades de administrador.
• IDOR (Insecure Direct Object Reference): modificar el ID en la URL para acceder a los datos de otros usuarios.
• Omisión de autenticación: acceder a páginas protegidas sin haber iniciado sesión.

SSRF ya no aparece como categoría independiente en OWASP Top 10 2025 y ha sido absorbida dentro de Broken Access Control, al considerarse una consecuencia directa de controles de acceso deficientes a nivel de red y aplicación.

A continuación, uno de los OWASP Top 10 ejemplos más claros (IDOR):

// URL normal
https://ejemplo.com/user/profile?id=1234

// Ataque IDOR: cambiar el ID para acceder al perfil de otro usuario
https://ejemplo.com/user/profile?id=5678

Si la aplicación no verifica que el usuario conectado tiene derecho a acceder al perfil 5678, se trata de un fallo IDOR.

Cómo protegerse:

• Implementa una verificación del lado del servidor para cada solicitud.
• Utiliza identificadores no predecibles (UUID en lugar de enteros secuenciales).
• Aplica el principio de mínimo privilegio: otorga únicamente los permisos necesarios.
• Prueba sistemáticamente los controles de acceso con diferentes niveles de privilegios.
• Registra los intentos de acceso no autorizado.
• Para mitigar SSRF, utiliza una lista blanca (whitelist) estricta de URLs/dominios autorizados y bloquea el acceso a rangos de IP privadas.

A02 – Configuración de Seguridad Incorrecta (Security Misconfiguration)

Descripción

Los errores de configuración se encuentran entre las vulnerabilidades más comunes. Incluyen configuraciones por defecto no seguras, servicios innecesarios activados, errores detallados expuestos a los usuarios, etc.

Ejemplos

• Cuentas por defecto sin modificar: admin/admin.
• Directorios/archivos sensibles accesibles: .git/, .env, backup.sql.
• Mensajes de error detallados que exponen la pila tecnológica (stack).
• Cabeceras de seguridad ausentes: X-Frame-Options, CSP, X-Content-Type-Options.
• CORS mal configurado: permitiendo cualquier origen.

Cómo protegerse

• Elimina las cuentas por defecto y los servicios no utilizados.
• Configura páginas de error genéricas (sin stack traces en producción).
• Implementa las cabeceras de seguridad: CSP, HSTS, X-Frame-Options, etc.
• Escanea regularmente con herramientas como Nessus, OpenVAS, Lynis.
• Sigue las guías de fortalecimiento (CIS Benchmarks).
• Aplica el principio de mínimo privilegio para todos los servicios.

A03 – Fallos en la Cadena de Suministro de Software (Software Supply Chain Failures)

Descripción

Esta categoría es una evolución directa de Vulnerable and Outdated Components (A06:2021). Amplía el foco a toda la cadena de suministro de software: dependencias, procesos de build, pipelines CI/CD, registries de paquetes y mecanismos de distribución.

El riesgo no es solo usar componentes vulnerables, sino confiar en software cuyo origen, integridad o proceso de entrega no está controlado. Puedes consultar el desglose completo de CWEs de esta categoría aquí.

Ejemplos de ataques

• Uso de versiones vulnerables de bibliotecas (ej. Log4Shell).
• Ausencia de escaneo de vulnerabilidades en los pipelines.
• Errores de CI/CD: desde permisos incorrectos hasta Cache Poisoning y secuestros de runners.
• Un nuevo vector de ataque relacionado es el slopesquatting: La IA a menudo genera bibliotecas inexistentes. Posteriormente, los atacantes identifican los nombres de estas bibliotecas y las publican en un Package Registry. Los desarrolladores, sin sospechar nada, obtienen una biblioteca que parece legítima pero que contiene malware en su interior.

Cómo protegerse

• Inventaría todas las dependencias (SBOM – Software Bill of Materials).
• Automatiza las actualizaciones: Dependabot, Renovate, Snyk.
• Escanea vulnerabilidades: npm audit, OWASP Dependency-Check, Trivy.
• Utiliza tus propios Package Registries (Artifactory, Nexus): es el método más fiable para protegerte contra la suplantación de paquetes.
• Verifica las bibliotecas que instalas y sus dependencias: número de estrellas en GitHub, fecha de publicación, etc.
• Asegura los pipelines CI/CD: autenticación fuerte, registro de logs, controles de acceso.

A04 – Fallos Criptográficos (Cryptographic Failures)

Descripción

Anteriormente conocida como “Exposición de Datos Sensibles”, esta categoría cubre los fallos relacionados con el cifrado de datos sensibles: contraseñas, números de tarjetas de crédito, datos médicos, etc.

Ejemplos de ataques

• Contraseñas almacenadas en texto plano o con un hash débil (MD5, SHA1).
• Transmisión de datos sensibles en HTTP (sin HTTPS).
• Claves de cifrado débiles o codificadas directamente en el código fuente.
• Gestión incorrecta de certificados SSL/TLS.

Ejemplo concreto

// INCORRECTO: contraseña almacenada en texto plano en la base de datos
INSERT INTO users (username, password) VALUES ('alice', 'contraseña123');

// CORRECTO: contraseña hasheada con bcrypt
const hashedPassword = await bcrypt.hash('contraseña123', 10);
INSERT INTO users (username, password) VALUES ('alice', hashedPassword);

Cómo protegerse

• Utiliza siempre HTTPS (con un certificado SSL/TLS válido).
• Hashea las contraseñas con bcrypt, Argon2 o PBKDF2 (nunca MD5/SHA1).
• Cifra los datos sensibles en reposo (en la base de datos).
• Nunca almacenes claves de cifrado en el código fuente (utiliza gestores de secretos).
• Desactiva los algoritmos de cifrado obsoletos (TLS 1.0, TLS 1.1).
• Utiliza HSTS (HTTP Strict Transport Security) para forzar el uso de HTTPS.

A05 – Inyección (Injection)

Descripción

Las inyecciones ocurren cuando una aplicación envía datos no confiables a un intérprete (SQL, NoSQL, LDAP, comandos del sistema, etc.) sin una validación o un escapado adecuados.

Ejemplos de ataques

• Inyección SQL: manipular consultas SQL para extraer, modificar o eliminar datos.
• Inyección NoSQL: explotar bases de datos como MongoDB, CouchDB, etc.
• Inyección de comandos del SO: ejecutar comandos del sistema.
• Inyección LDAP: manipular consultas de directorio.

Ejemplo concreto: Inyección SQL

// INCORRECTO: vulnerable a inyección SQL
const username = req.body.username;
const password = req.body.password;
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;

// Ataque: el usuario introduce como nombre de usuario: admin'--
// La consulta se convierte en:
// SELECT * FROM users WHERE username = 'admin'--' AND password = ''
// El -- comenta el resto de la consulta, omitiendo la contraseña

// CORRECTO: utilizar consultas preparadas
const query = 'SELECT * FROM users WHERE username = ? AND password = ?';
db.execute(query, [username, password]);

Cómo protegerse

• Utiliza consultas preparadas o parametrizadas (prepared statements).
• Utiliza un ORM (Object-Relational Mapping): Sequelize, TypeORM, Prisma, etc.
• Valida y sanea todas las entradas de usuario.
• Aplica el principio de mínimo privilegio a las cuentas de la base de datos.
• Escapa los caracteres especiales si no es posible usar consultas preparadas.
• Utiliza un WAF (Web Application Firewall) para detectar intentos de inyección.

A06 – Diseño Inseguro (Insecure Design)

Descripción

Esta categoría se refiere a fallos en el diseño de la aplicación, no a errores de implementación. una aplicación puede estar perfectamente codificada pero tener una arquitectura fundamentalmente insegura.

Ejemplos

• Ausencia de limitación de peticiones (rate limiting): permite ataques de fuerza bruta.
• Falta de validación de lógica de negocio: ej: comprar artículos con un precio negativo.
• Flujos de trabajo mal diseñados: ej: restablecimiento de contraseña sin verificación de identidad.
• Ausencia de segregación de entornos: desarrollo, pruebas y producción comparten los mismos recursos.

Cómo protegerse

• Realiza modelado de amenazas (Threat Modeling): identifica las amenazas desde la fase de diseño.
• Aplica el principio de “Seguridad por Diseño” (Secure by Design): integra la seguridad desde la arquitectura.
• Realiza revisiones de diseño con expertos en seguridad.
• Utiliza patrones de diseño seguros.
• Ejecuta pruebas de seguridad tempranas (shift-left security).

A07 – Fallos de Identificación y Autenticación (Identification and Authentication Failures)

Descripción

Los fallos de autenticación permiten a los atacantes comprometer cuentas de usuario, robar sesiones o eludir completamente la autenticación.

Ejemplos

• Ataques de fuerza bruta: ausencia de limitación de peticiones en el login.
• Fijación de sesión (Session fixation): el atacante impone un ID de sesión a la víctima.
• Credential stuffing: reutilización de contraseñas robadas de otros servicios.
• Tokens de sesión predecibles.
• Ausencia de MFA (Autenticación Multifactor).

Cómo protegerse

• Implementa la MFA (autenticación de dos factores).
• Aplica limitación de peticiones (rate limiting) en los endpoints de login.
• Utiliza tokens de sesión impredecibles y seguros (generados en el lado del servidor).
• Establece una política de contraseñas fuertes (longitud mínima, complejidad).
• Verifica contraseñas comprometidas con la API de HaveIBeenPwned.
• Configura sesiones con tiempo de expiración (timeout) e invalidación en el servidor.
• Regenera los ID de sesión después del login.

A08 – Fallos de Integridad del Software y de los Datos (Software and Data Integrity Failures)

Descripción

Esta categoría cubre los riesgos relacionados con la falta de verificación de la integridad del código, los datos y las actualizaciones. Incluye ataques a los pipelines CI/CD, la cadena de suministro de software y la deserialización insegura.

Ejemplos

• Deserialización insegura: ejecución de código malicioso a través de objetos deserializados.
• Ataque a la cadena de suministro: compromiso de una dependencia (ej: ataque a SolarWinds).
• Actualización automática no firmada: un atacante inyecta código malicioso a través de una falsa actualización.
• CI/CD comprometido: inyección de código malicioso en el pipeline de despliegue.

Cómo protegerse

• Verifica las firmas digitales de las actualizaciones y dependencias.
• Utiliza sumas de verificación/hashes para comprobar la integridad de los archivos.
• Asegura los pipelines CI/CD: autenticación fuerte, registro de logs, controles de acceso.
• Evita la deserialización de datos no confiables.
• Utiliza registros de dependencias privados y verificados.
• Audita regularmente las dependencias de terceros.

A09 – Fallos en el Registro de Seguridad y Alertas (Security Logging and Alerting Failures)

Descripción

La ausencia de registros, correlación y monitorización continua impide detectar comportamientos anómalos, generar alertas fiables y responder a incidentes de seguridad de forma oportuna. En OWASP 2025, el término alerting se entiende como parte de un proceso más amplio de monitoring.

Ejemplos

• Ningún registro de intentos de conexión fallidos.
• Logs no centralizados: imposibles de correlacionar.
• Ninguna alerta sobre actividades sospechosas.
• Logs almacenados de forma no segura: accesibles o modificables por un atacante.

Cómo protegerse

• Registra todos los eventos de seguridad: inicios de sesión, accesos denegados, modificaciones de configuración, etc.
• Centraliza los logs: ELK Stack, Splunk, Graylog.
• Implementa alertas automáticas: intentos de fuerza bruta, elevaciones de privilegios anómalas.
• Protege los logs: acceso restringido, inmutabilidad.
• Audita los logs regularmente.
• Prueba la detección de incidentes: ejercicios de red team/blue team.

A10 – Manejo Incorrecto de Condiciones Excepcionales (Mishandling of Exceptional Conditions)

Descripción

Esta categoría es nueva y agrupa 24 CWE, como se detalla en la documentación oficial de A10. No se limita al manejo incorrecto de excepciones (try/catch mal implementados), sino que cubre fallos estructurales de lógica y control de estados anómalos, incluyendo failing open, errores lógicos en flujos de negocio y race conditions derivadas de una gestión incorrecta de la concurrencia.

Ejemplos de ataques

• Fuga de información: la introducción de datos de usuario con formato incorrecto en un parámetro provoca un error en la consulta a la base de datos. Este error, con sus detalles técnicos, se muestra a los usuarios, revelando información técnica.
• Denegación de servicio (DoS): un error no gestionado provoca que la aplicación o un hilo se bloquee, dejando de responder.
• Corrupción de datos o bypass de lógica: una condición de carrera (Race Condition) provocada por un manejo inadecuado de la concurrencia permite realizar acciones no autorizadas.

Cómo protegerse

• Implementa un manejo de errores global y centralizado (try-catch-finally) para asegurar que ninguna excepción quede sin gestionar.
• Nunca expongas trazas de pila (stack traces) ni información técnica detallada en los mensajes de error de producción. Usa páginas de error genéricas.
• Valida y sanea todas las entradas para prevenir que la aplicación llegue a estados inesperados o erróneos.
• Diseña la lógica de negocio para manejar condiciones de carrera (Race Conditions) de forma segura, especialmente en operaciones críticas (transacciones, acceso a recursos compartidos).

OWASP Top 10 y el Impacto de los LLM

OWASP no establece una relación directa entre esta edición del Top 10 y la IA generativa. La relación que planteamos a continuación es un análisis editorial basado en patrones observados en entornos reales de desarrollo asistido por LLMs, no una postura oficial del proyecto OWASP.

Si no se le indica explícitamente a un LLM que priorice la seguridad, generará código que simplemente funciona. El control de acceso, la configuración correcta y otros requisitos no funcionales se vuelven secundarios. Es por esto que Security Misconfiguration y Broken Access Control ocupan las primeras posiciones.

Paralelamente, las vulnerabilidades relacionadas con la criptografía y las inyecciones han descendido en el ranking. Los frameworks y bibliotecas modernos asumen la mayor parte de la complejidad en estas áreas y ofrecen mecanismos seguros “por defecto”.

Prompt Injection

Cuando la IA no solo se utiliza como herramienta de desarrollo, sino que se integra en la propia aplicación, surge una nueva clase de ataques: Prompt Injection. En este caso, el atacante no manipula el código directamente, sino el contexto en el que opera el modelo.

Para profundizar en este tema, recomendamos consultar el proyecto específico OWASP Top 10 para LLM.

El ejemplo más simple es la sustitución o ampliación de la entrada del usuario de manera que la IA comience a ejecutar instrucciones no deseadas: ignorar reglas de negocio, revelar datos internos o tomar decisiones a favor del atacante.

Mejores Prácticas para Mitigar Riesgos de IA

Cambios en los procesos

• Implementación obligatoria de code review, especialmente para el código generado.
• Definir un conjunto de herramientas corporativo y utilizar suscripciones de equipo para monitorizar.
• Configurar la exclusión de contenido (Content Exclusion) para herramientas como GitHub Copilot. Es necesario excluir archivos .env, appsettings y otras configuraciones que puedan contener secretos.
• Formación interna en prompt engineering.

Cambios tecnológicos

• Implementación de análisis estático de código, como SonarQube.
• Configuración de tu propio Registry para bibliotecas: Artifactory, Nexus, etc.

Herramientas para Probar las Vulnerabilidades del OWASP Top 10

Herramientas automatizadas

• OWASP ZAP (Zed Attack Proxy): escáner de vulnerabilidades web gratuito y de código abierto.
• Burp Suite: herramienta profesional de pruebas de seguridad (versión Community gratuita disponible).
• Nikto: un escáner de servidores web muy conocido.
• SQLMap: herramienta especializada en la detección y explotación de inyecciones SQL.
• Nuclei: escáner de vulnerabilidades moderno basado en plantillas.
• Existen muchas más herramientas para escanear vulnerabilidades web que pueden complementar estas.

Herramientas de escaneo de dependencias

• npm audit: para Node.js.
• pip-audit: para Python.
• OWASP Dependency-Check: para múltiples lenguajes.
• Snyk: plataforma SaaS de seguridad de dependencias.

Plataformas de entrenamiento

• DVWA (Damn Vulnerable Web Application): aplicación deliberadamente vulnerable.
• WebGoat: proyecto OWASP de formación interactiva.
• Juice Shop: aplicación de e-commerce deliberadamente vulnerable (OWASP).
• PortSwigger Web Security Academy: laboratorios gratuitos que cubren todas las vulnerabilidades OWASP.

Preguntas Frecuentes (FAQ)

El Futuro de la Seguridad de Aplicaciones

El nuevo ranking de OWASP ilustra claramente cómo ha evolucionado la naturaleza de los problemas de seguridad.

Es fundamental recordar que la IA sigue siendo una herramienta. La responsabilidad del código recae en las personas, y son las decisiones de ingeniería, los procesos y las revisiones los que continúan determinando si un sistema será seguro.

Para los interesados en la metodología o en contribuir, el proyecto es de código abierto en su repositorio de GitHub.

Advertencia Ética

Este artículo se publica con fines educativos y preventivos. Las técnicas y vulnerabilidades descritas en este artículo solo deben probarse en:

• Tus propias aplicaciones e infraestructuras.
• Aplicaciones de prueba diseñadas específicamente para el aprendizaje (DVWA, WebGoat, Juice Shop).
• Sistemas para los cuales has recibido una autorización explícita por escrito (misiones de pentesting).

Probar vulnerabilidades en sistemas sin autorización es ilegal y constituye un delito penal en la mayoría de los países. Desde EsGeeks no nos hacemos responsables del uso abusivo o ilegal de la información contenida en este artículo. Utiliza estos conocimientos de manera ética y responsable para mejorar la seguridad, no para perjudicar.