OWASP Top 10 2017: lo que sigue rompiendo aplicaciones web
Lectura crítica de los diez riesgos más comunes en aplicaciones web — inyección, autenticación rota, exposición de datos sensibles, XXE — con ejemplos extraídos de auditorías reales.
Inyección sigue siendo A1 por una razón
La concatenación de strings para construir SQL no es un problema de hace veinte años — sigue apareciendo en auditorías nuevas, especialmente en capas internas de servicios que el equipo asume seguras porque no están expuestas. Cualquier punto donde una entrada cruza una frontera de confianza necesita parametrización: prepared statements, ORM bien usado o, en última instancia, escapado explícito documentado.
-- MAL
query = "SELECT * FROM users WHERE email = '" + email + "'";
-- BIEN
PreparedStatement ps = con.prepareStatement(
"SELECT * FROM users WHERE email = ?");
ps.setString(1, email);Autenticación rota y gestión de sesiones
Cookies de sesión sin HttpOnly ni Secure, identificadores de sesión predecibles, no rotar el ID tras login, recuperación de contraseña por preguntas secretas, contadores de intentos sólo en el cliente. Cada uno por separado parece menor; combinados son una toma de cuenta a un paso.
La regla simple: usar el módulo de sesión del framework, configurarlo con valores explícitos (no defaults), rotar el ID en cada cambio de privilegio y registrar todo intento fallido con suficiente contexto para detectar password spraying.
Datos sensibles en tránsito y en reposo
TLS 1.2+ con ciphersuites modernas y HSTS preload son el mínimo en tránsito. En reposo: bcrypt/argon2 para contraseñas (nunca SHA-x sin sal), cifrado a nivel de columna para PII, y un proceso documentado de gestión de claves. Cifrar la base de datos entera con el mismo KMS que la aplicación usa para todo no aporta gran cosa si el atacante ya tiene la aplicación.