Después de decenas de auditorías de seguridad a empresas españolas de todos los tamaños, hemos identificado patrones claros en las vulnerabilidades que aparecen una y otra vez. Este artículo no es una copia del OWASP Top 10 — es lo que encontramos de verdad cuando hacemos pentesting manual a aplicaciones web en producción.
1. IDOR (Insecure Direct Object Reference)
La vulnerabilidad que más encontramos, con diferencia. Consiste en que un usuario puede acceder a recursos de otro usuario simplemente cambiando un identificador en la URL o en una petición API. Por ejemplo: cambiar /api/facturas/123 por /api/facturas/124 para ver la factura de otro cliente. Los escáneres automáticos no detectan IDOR porque requiere entender la lógica de negocio y probar con múltiples cuentas de usuario.
2. Fallos de autorización entre roles
Relacionado con IDOR pero más sutil: un usuario con rol de lectura puede ejecutar acciones de administrador si conoce el endpoint. Muchas aplicaciones validan roles solo en el frontend (mostrando u ocultando botones) pero no en el backend. Un atacante que intercepte las peticiones HTTP puede ejecutar cualquier acción independientemente de su rol asignado.
3. Inyección SQL (SQLi)
Sigue apareciendo en 2025, especialmente en aplicaciones legacy o en funcionalidades secundarias que no pasan por el ORM principal. Los puntos más comunes: filtros de búsqueda, exportaciones a CSV, informes personalizados y funcionalidades de administración que se desarrollaron con menos rigor que el core de la aplicación. Una SQLi bien explotada puede significar acceso completo a la base de datos.
4. Cross-Site Scripting (XSS)
XSS stored sigue siendo un problema grave, especialmente en aplicaciones SaaS donde el contenido de un usuario se muestra a otros. Los frameworks modernos como React protegen contra XSS básico, pero los problemas aparecen en editores de texto enriquecido, funcionalidades de markdown, atributos HTML dinámicos y contextos donde se usa dangerouslySetInnerHTML o equivalentes.
5. SSRF (Server-Side Request Forgery)
Cada vez más común en aplicaciones que integran servicios externos: importación de URLs, previsualizaciones de enlaces, webhooks, integraciones con APIs de terceros. Un SSRF permite al atacante hacer peticiones desde el servidor de la aplicación a recursos internos, pudiendo acceder a metadatos de cloud (169.254.169.254), servicios internos, o incluso pivotar a otros sistemas de la red.
6. Configuraciones por defecto en cloud
Buckets S3 públicos, bases de datos sin autenticación expuestas a internet, secretos hardcodeados en repositorios, roles IAM excesivamente permisivos. La migración a cloud no significa automáticamente más seguridad. De hecho, la complejidad de las configuraciones de AWS, GCP o Azure introduce nuevos vectores de ataque que muchos equipos de desarrollo no dominan.
7. Autenticación débil y gestión de sesiones
Tokens JWT sin expiración, sesiones que no se invalidan al cambiar la contraseña, falta de protección contra fuerza bruta, recuperación de contraseña insegura. También encontramos frecuentemente APIs que aceptan tokens expirados o que no validan correctamente la firma del JWT.
8. Exposición de información sensible
APIs que devuelven más datos de los necesarios, mensajes de error que revelan la estructura interna, paneles de administración accesibles sin autenticación, archivos de configuración expuestos (.env, .git, backup.sql). Un caso habitual: la API devuelve el objeto de usuario completo incluyendo hash de contraseña, cuando el frontend solo necesita nombre y email.
9. Falta de rate limiting
Endpoints de login sin protección contra fuerza bruta, APIs de envío de email sin límite (permitiendo spam masivo desde tu dominio), funcionalidades de OTP que permiten intentos ilimitados. La falta de rate limiting convierte vulnerabilidades teóricas en explotables y puede llevar a denegación de servicio o a comprometer cuentas por fuerza bruta.
10. Dependencias vulnerables
Librerías desactualizadas con CVEs conocidas, frameworks sin parches de seguridad, componentes de terceros abandonados. El caso más extremo que encontramos: una aplicación en producción usando una versión de Log4j vulnerable a Log4Shell, meses después de la publicación del parche. La gestión de dependencias no es glamurosa, pero es crítica.
Conclusión: la seguridad no es un producto, es un proceso
Estas 10 vulnerabilidades representan la gran mayoría de los hallazgos en nuestros pentests. Lo que tienen en común es que ninguna de ellas se detecta eficazmente con escáneres automáticos. Requieren pruebas manuales, contexto de negocio y la capacidad de pensar como un atacante. Si tu empresa no ha realizado un pentest manual reciente, es probable que varias de estas vulnerabilidades estén presentes en tus sistemas ahora mismo.