OWASP Top 10: vulnerabilidades web críticas y principios de desarrollo seguro

El OWASP Top 10 es el documento de referencia más influyente en seguridad de aplicaciones web. Publicado por la Open Web Application Security Project (OWASP), una fundación sin ánimo de lucro dedicada a mejorar la seguridad del software, el Top 10 lista las diez categorías de vulnerabilidades web más críticas y prevalentes. Para cualquier desarrollador, arquitecto de software o responsable de seguridad, conocer el OWASP Top 10 es conocimiento fundamental.

Por qué importa el OWASP Top 10

La mayoría de los ataques exitosos contra aplicaciones web no explotan vulnerabilidades exóticas y desconocidas: explotan las mismas categorías de errores que aparecen en el OWASP Top 10 desde hace años. Inyección SQL, configuraciones inseguras, autenticación deficiente, exposición de datos sensibles. Son vulnerabilidades bien documentadas, con contramedidas conocidas, que siguen siendo extraordinariamente comunes porque los desarrolladores no siempre tienen formación en seguridad y porque la presión por entregar funcionalidades supera frecuentemente la atención a la seguridad.

Las categorías del OWASP Top 10 (versión actualizada)

A01: Control de acceso roto

La categoría más común en las aplicaciones web actuales. Ocurre cuando una aplicación no impone correctamente las restricciones sobre qué pueden hacer los usuarios autenticados. Ejemplos: un usuario normal puede acceder a funciones de administrador modificando la URL, un usuario puede ver los datos de otros usuarios cambiando un parámetro ID en la petición, o una API devuelve más datos de los necesarios (exposición masiva de datos).

Contramedida: implementar control de acceso en el servidor (nunca confiar en el cliente), aplicar el principio de mínimo privilegio, denegar acceso por defecto y auditar regularmente los permisos.

A02: Fallos criptográficos

Anteriormente llamada "Exposición de datos sensibles", esta categoría cubre todos los fallos relacionados con el uso incorrecto de la criptografía: datos sensibles transmitidos sin cifrar, uso de algoritmos obsoletos (MD5, SHA-1 para contraseñas), claves criptográficas débiles o hardcodeadas en el código, y falta de cifrado en reposo para datos críticos.

Contramedida: cifrar todos los datos sensibles en reposo y en tránsito, usar algoritmos modernos (AES-256, TLS 1.3, bcrypt/Argon2 para contraseñas), nunca hardcodear claves en el código fuente.

A03: Inyección

La inyección ocurre cuando datos no confiables son enviados a un intérprete (SQL, NoSQL, OS, LDAP) como parte de un comando o consulta. El tipo más conocido es la inyección SQL, pero también incluye inyección de comandos OS, inyección LDAP y otros.

Contramedida: usar consultas parametrizadas o prepared statements, validar y sanitizar todas las entradas del usuario, aplicar el principio de mínimo privilegio en las cuentas de base de datos.

A04: Diseño inseguro

Una categoría introducida en las versiones recientes que reconoce que muchas vulnerabilidades son consecuencia de decisiones de diseño erróneas, no de errores de implementación. Si el diseño de la aplicación no contempla los casos de abuso, ninguna implementación perfecta puede compensarlo.

Contramedida: modelado de amenazas durante el diseño, diseño de arquitectura con seguridad integrada (security by design), revisiones de diseño antes de la implementación.

A05: Configuración de seguridad incorrecta

Una de las categorías más prevalentes. Incluye: funciones innecesarias habilitadas, permisos por defecto sin cambiar, mensajes de error que revelan información sensible, software sin actualizar, headers de seguridad HTTP ausentes y configuraciones por defecto inseguras en frameworks y bibliotecas.

Contramedida: proceso de hardening documentado, revisiones de configuración regulares, automatización de la detección de configuraciones inseguras, desactivar todo lo que no sea estrictamente necesario.

Para comprender cómo las configuraciones inseguras de los servidores y servicios en la nube se combinan con estas vulnerabilidades web, el artículo sobre seguridad en la nube ofrece el complemento perfecto desde la perspectiva de la infraestructura.

A06: Componentes vulnerables y desactualizados

Las aplicaciones web modernas usan decenas o cientos de bibliotecas y frameworks de terceros. Si alguno tiene una vulnerabilidad conocida sin parchear, toda la aplicación queda expuesta. El 86% de los sitios web tienen al menos una biblioteca JavaScript vulnerable según los análisis del sector.

Contramedida: inventario de todos los componentes de terceros y sus versiones, herramientas de análisis de composición de software (SCA) como OWASP Dependency-Check, Snyk o Dependabot para detectar automáticamente componentes vulnerables.

A07: Fallos de identificación y autenticación

Implementaciones incorrectas de los mecanismos de autenticación: contraseñas débiles permitidas, ausencia de protección contra ataques de fuerza bruta, tokens de sesión predecibles, ausencia de 2FA para funciones críticas, gestión insegura del cierre de sesión.

Contramedida: implementar 2FA, usar gestión de sesiones segura, limitar los intentos de login fallidos, verificar contraseñas contra listas de contraseñas comprometidas conocidas.

A08: Fallos en la integridad del software y los datos

Código y actualizaciones de software que se incorporan sin verificar su integridad: pipelines de CI/CD inseguros, dependencias de fuentes no verificadas, deserialización insegura. El ataque a SolarWinds (2020) es el ejemplo más dramático: los atacantes comprometieron el proceso de build del software para inyectar malware en actualizaciones legítimas distribuidas a miles de clientes.

Contramedida: verificar la integridad criptográfica de los componentes descargados, asegurar el pipeline de CI/CD, implementar firmas de código.

A09: Fallos en el registro y monitorización de seguridad

Si una aplicación no registra los eventos de seguridad relevantes o no monitoriza esos registros, los ataques pueden pasar desapercibidos durante meses. El tiempo medio de detección de una brecha de seguridad sigue siendo superior a 200 días en muchas organizaciones.

Contramedida: logging de todos los eventos de autenticación, control de acceso y errores de validación, centralización de logs en un SIEM, alertas automáticas para patrones anómalos.

A10: Server-Side Request Forgery (SSRF)

Una vulnerabilidad en auge con la proliferación de arquitecturas cloud. Ocurre cuando una aplicación web hace peticiones HTTP a un servidor externo usando una URL proporcionada por el usuario, sin validar correctamente el destino. Un atacante puede usar esto para acceder a recursos internos de la infraestructura, incluyendo los metadatos de las instancias cloud.

Contramedida: validar y filtrar todas las URLs proporcionadas por el usuario, usar listas blancas de dominios permitidos, segmentar la red interna.

Conclusión

El OWASP Top 10 no es una lista de vulnerabilidades exóticas: es un inventario de los mismos errores que se repiten año tras año en miles de aplicaciones. Para los desarrolladores, integrarlo en el proceso de desarrollo (desde el diseño hasta el testing) es la forma más efectiva de reducir la superficie de ataque de cualquier aplicación web.