Buenas prácticas y seguridad avanzada

Ya dispone de una aplicación en la que las identidades se verifican, las contraseñas se almacenan correctamente con hash y los accesos están controlados. Eso es lo necesario, pero no lo suficiente. Los incidentes de los que se leen crónicas casi nunca empiezan con «el atacante rompió la autenticación». Empiezan con un endpoint de Actuator que se dejó abierto, una clave de API en un repositorio público, una biblioteca de hace tres años o una traza de excepción mostrada en producción que revelaba la ruta completa del servidor.

Estos fallos tienen un punto en común: ninguno es un defecto del código de la aplicación. Son defectos de configuración, de explotación y de higiene de dependencias. De hecho, OWASP los clasifica por separado: «configuración de seguridad incorrecta» y «componentes vulnerables o desactualizados» son dos categorías distintas de su ranking de los diez principales riesgos.

Esta última lección reúne, por tanto, los elementos que no pertenecen a ninguna de las anteriores pero que determinan la solidez real del sistema: las cabeceras que el navegador debe recibir, la forma de imponer HTTPS sin provocar un bucle de redirección, la limitación de tasa, el registro útil de eventos —y el que genera por sí mismo la fuga—, la gestión de secretos y la vigilancia de las dependencias.