Las 10 principales vulnerabilidades en aplicaciones web encontradas en 2024
Las aplicaciones web son un objetivo habitual para los atacantes porque:
Son fácilmente localizables en línea.
Suelen contener vulnerabilidades heredadas de bibliotecas de código abierto.
Los desarrolladores están bajo presión para lanzar código rápidamente, lo que lleva a descuidar la seguridad.
Los cambios constantes en el código y las nuevas técnicas de ataque hacen que algunas vulnerabilidades pasen desapercibidas si solo se prueban una vez al año.
Por eso, las aplicaciones web deben recibir tanta atención en seguridad como la que despiertan entre los atacantes.
En Claranet analizamos los resultados de 500 pruebas de penetración realizadas en 2024 y entrevistamos a nuestro equipo de expertos para identificar los errores más comunes y cómo mitigarlos.
Resumen ejecutivo
Aunque muchas vulnerabilidades coinciden con el OWASP Top 10, detectamos variaciones:
Muchas aplicaciones presentan fallos fácilmente explotables que pueden combinarse para lograr impactos mayores.
Eliminar estos errores básicos es crucial para proteger la confidencialidad, integridad y disponibilidad de las aplicaciones.
Se observa una reducción de vulnerabilidades clásicas como inyecciones SQL, pero XSS sigue muy presente.
Nuestros clientes han comenzado a implementar prácticas como DevSecOps, formación en seguridad y pruebas continuas.
1. XSS reflejado y almacenado
2.570 casos detectados.
Afecta a la mayoría de las aplicaciones analizadas desde hace 5 años.
¿Qué es?
XSS reflejado: la entrada del usuario se refleja sin validar en la respuesta del servidor.
XSS almacenado: los datos maliciosos se guardan en el servidor y se muestran a otros usuarios.
Cómo defenderse
Usar WAF (Web Application Firewall).
Sanear y escapar entradas de usuario.
Aplicar Content Security Policy (CSP).
Usar cookies con atributos Secure y HttpOnly.
Evitar JavaScript inline.
Usar frameworks modernos (React, Angular, Vue).
Preferir métodos como textContent en lugar de innerHTML.
Auditar librerías de terceros.
Realizar pruebas de seguridad automatizadas y manuales.
Escapar datos según el contexto (HTML, URL, JS).
2. Bibliotecas JavaScript desactualizadas
1.032 casos detectados.
Pueden facilitar XSS, Denegación de Servicio o fugas de información.
Cómo defenderse
Actualizar dependencias regularmente.
Verificar el mantenimiento activo de cada librería.
Usar alternativas modernas si es necesario.
Aplicar auditorías de seguridad regulares.
Educar al equipo de desarrollo sobre estos riesgos.
Planificar la migración de librerías obsoletas.
3. Clickjacking
Presente en el 80 % de las aplicaciones evaluadas.
¿Qué es?
El usuario hace clic en un botón invisible superpuesto a una web legítima, lo que permite al atacante ejecutar acciones maliciosas.
Cómo defenderse
Implementar frame-busting.
Usar el encabezado X-Frame-Options.
Aplicar CSP con frame-ancestors.
4. Divulgación de encabezados del servidor
4.631 casos detectados.
Muchos servidores revelan el software y versión utilizados, lo que facilita la identificación de vulnerabilidades.
Cómo defenderse
Suprimir o limitar el encabezado Server.
Usar proxies inversos o balanceadores de carga.
- Aplicar CSP para minimizar otros riesgos asociados.
5. Cookies sin atributos de seguridad
769 cookies detectadas sin atributos clave.
Cookies de sesión sin Secure, HttpOnly o SameSite son vulnerables a XSS y CSRF.
Cómo defenderse
Usar Secure con HTTPS.
Aplicar HttpOnly para evitar acceso desde JavaScript.
Usar SameSite para limitar el envío en peticiones cruzadas.
6. Uso de TLS 1.0 y 1.1
3.703 casos de TLS 1.0.
4.062 casos de TLS 1.1.
Protocolos antiguos y ya considerados inseguros.
Cómo defenderse
Desactivar TLS 1.0 y 1.1.
Usar solo TLS 1.2 o TLS 1.3.
Activar cipher suites seguras.
Aplicar HSTS.
Probar la configuración con herramientas como SSL Labs.
7. Sin bloqueo de cuentas tras intentos fallidos
35 casos detectados en 2024.
Permite ataques de fuerza bruta o relleno de credenciales.
Cómo defenderse
Limitar intentos de login por IP/usuario.
Introducir retrasos progresivos.
Implementar MFA y CAPTCHA.
Bloquear IPs sospechosas.
Usar tokens en lugar de contraseñas.
Notificar actividad sospechosa.
Aplicar recuperación controlada tras el bloqueo.
8. Encabezados HTTP de seguridad ausentes
Más del 50 % de las aplicaciones los omiten.
Vulnerabilidad | Encabezado recomendado |
XSS | Content-Security-Policy |
Clickjacking | X-Frame-Options |
Transmisión insegura | Strict-Transport-Security |
Confusión MIME | X-Content-Type-Options: nosniff |
CSRF | Atributo SameSite en cookies |
Exposición de referencias | Referrer-Policy |
Datos sensibles en caché | Cache-Control, Pragma |
Tipo de contenido incorrecto | Content-Type |
9. Mensajes de error demasiado detallados
60 % de las aplicaciones muestran errores con información excesiva.
Cómo defenderse
Mostrar mensajes genéricos al usuario.
Registrar errores detallados solo internamente.
Usar páginas de error personalizadas.
Restringir los mensajes detallados a usuarios autorizados.
Utilizar herramientas de seguimiento de errores.
Cifrar o enmascarar datos en logs.
10. Carga de archivos maliciosos
574 aplicaciones vulnerables.
Permiten subir archivos sin validaciones, facilitando la ejecución de código malicioso.
Cómo defenderse
Restringir los tipos de archivo.
Validar tipo MIME y contenido.
Limitar tamaño de archivos.
Almacenar fuera del directorio web.
Deshabilitar permisos de ejecución.
Escanear archivos con antivirus.
Monitorizar y registrar las cargas.
Usar una CDN para servir los archivos.
Futuro de la seguridad en aplicaciones web: IA y nuevos retos
Desde Claranet, hemos observado un aumento del uso de modelos de lenguaje (LLM) integrados en aplicaciones web. Estos traen nuevos vectores de ataque:
Inyección de prompts.
Fugas de datos sensibles.
APIs mal protegidas.
Entradas adversarias.
Manipulación mediante sesgos.
También se han identificado riesgos al usarlos para programar: typosquatting, datos contaminados, código malicioso en repositorios o alucinaciones de IA.
Consejos para desarrolladores
Actualizar las bibliotecas JavaScript.
Escanear dependencias de código abierto y de terceros.
Aplicar DevSecOps con pruebas continuas.
Formar al equipo con programas como Application Security for Developers.
Si quieres saber más, contacta con nuestro equipo de expertos.