Por framework
Seguridad de Spring Boot — una referencia de hardening para producción
Una referencia de hardening para producción en Spring Boot: una lista de comprobación por prioridad más CVE de dependencias (Log4Shell), configuración/secretos de producción, autorización con Spring Security, exposición de Actuator, deserialización y SSRF. Defensiva, sin pasos de ataque.
Para: cualquiera que opere una app con Java / Spring Boot. Aquí no hay pasos de ataque — esta es una referencia práctica para el hardening: una lista de comprobación ordenada por prioridad, guía por área y autoverificación. Para el panorama entre frameworks, consulta el centro de seguridad por framework.
Lista de comprobación de hardening ordenada por prioridad
Realiza esta tabla de arriba abajo. P0 es un requisito previo, P1 es la fuente más frecuente de incidentes, P2 es higiene operativa continua.
P0 ── Requisito previo (hazlo primero)
Monitoreo de CVE de dependencias + parcheo rápido / sin detalle de errores en producción / externalizar los secretos
P1 ── Principal fuente de incidentes
Autorización con Spring Security (denegación por defecto, comprobaciones de propietario) / reducir la exposición de Actuator y de gestión
P2 ── Higiene operativa
Deserialización insegura / cabeceras, CSRF, sesión / SSRF
| Prioridad | Control | Detalles (Spring Boot) |
|---|---|---|
| P0 | Monitoreo de CVE de dependencias | osv-scanner / dependency-check; juzga por la versión en ejecución, parchea rápido (tipo Log4Shell) |
| P0 | Errores de producción | No expongas stack traces (server.error.include-stacktrace=never, etc.) |
| P0 | Externalizar secretos | Información de conexión/claves desde env/Vault, no en configuración escrita a mano. No los subas al repositorio |
| P1 | Autorización explícita | Denegación por defecto + seguridad a nivel de método (@PreAuthorize) + comprobaciones de propietario |
| P1 | Reducir la exposición de Actuator | Exposición mínima (p. ej. health) + autenticación requerida + puerto/frontera separados. No expongas env/heapdump |
| P1 | Deserialización | No deserialices datos no confiables de forma nativa. No dejes que SpEL evalúe la entrada |
| P2 | Inyección | Vincula con JPA/JdbcTemplate. Nunca construyas consultas por concatenación de cadenas |
| P2 | Cabeceras/CSRF/sesión | Cabeceras de Spring Security (HSTS, etc.), CSRF, atributos de cookie, fijación de sesión |
| P2 | SSRF | Lista de permitidos para las peticiones del lado del servidor + bloqueo de IP internas/metadatos |
1. CVE de dependencias y el ecosistema (P0)
Precisamente porque Spring está tan extendido, el fallo de una librería de dependencia se propaga a todos de golpe. Log4Shell es el símbolo de eso.
- Monitorea con una máquina los CVE de dependencias con osv-scanner u OWASP dependency-check, juzga por la versión en ejecución y parchea rápido (decide por la que está realmente construida, no por la declaración de pom.xml/gradle).
- Mantén Spring Boot y Java en versiones soportadas. No dejes versiones EOL en su sitio.
- Para el caso y la práctica consulta la disección de Log4Shell · el manual de respuesta a vulnerabilidades · monitorear los CVE de dependencias.
2. Configuración de producción y secretos (P0)
- En producción, no expongas el detalle de los errores (stack traces) — reduce las pistas que filtran la estructura interna y las versiones de dependencias.
- Mantén los secretos como la información de conexión y las claves fuera de application.properties/yml, inyectándolos desde env o un gestor de secretos (Vault, etc.). No los subas al repositorio (→ archivos .env y secretos).
- No habilites herramientas de desarrollo (devtools, etc.) en producción.
3. Autorización con Spring Security (P1 — la principal fuente)
Habitual (peligroso)
- valores por defecto laxos, no diseñados como permiso explícito
- protegido solo por patrones de URL, sin comprobación de método/propietario
- autenticado, pero «con sesión = permitido»
- un hueco de configuración deja pasar algún endpoint
Correcto
- denegación por defecto (solo pasa lo que permites explícitamente)
- autorización a nivel de método (
@PreAuthorize, etc.) + comprobaciones de propietario - verifica permiso/propietario en cada ruta de lectura/actualización/borrado
- construye la autorización de forma explícita, no dejada a los valores por defecto
Consulta qué es IDOR. La autenticación y la autorización son distintas; autoriza cerca de los datos.
4. Actuator y endpoints de gestión (P1)
- Restringe los endpoints de Actuator expuestos al mínimo (p. ej. solo health).
- Exige autenticación/autorización y mantenlos en un puerto separado / una frontera de red inalcanzable desde fuera.
- No expongas endpoints sensibles como
env,heapdumpologgers(fuga de información / trampolín para operaciones).
5. Deserialización insegura y evaluación de expresiones (P2)
- No deserialices datos no confiables de forma nativa (puede llevar a RCE en las condiciones adecuadas). Verifica la procedencia y, donde haga falta, restríngelo a un formato seguro como JSON (→ qué es RCE).
- No dejes que las plantillas o SpEL evalúen la entrada del usuario. Valida la entrada con Bean Validation, etc.
6. Inyección y acceso a datos (P2)
- SQL: vincula con JPA / JdbcTemplate; nunca construyas consultas por concatenación de cadenas (→ qué es la inyección SQL).
- Al emitir HTML desde una plantilla, aplica codificación de salida y no incrustes la entrada del usuario directamente (defensa contra XSS).
7. Cabeceras, HTTPS, sesión (P2)
- Usa las cabeceras de seguridad de Spring Security (HSTS sobre HTTPS, etc.). Comprueba tu propio sitio con el verificador de cabeceras de seguridad.
- Fuerza HTTPS. Tras un balanceador de carga, configúralo para detectar el esquema/IP de cliente correctos.
- Establece Secure/HttpOnly/SameSite en las cookies, mantén la protección CSRF (activa por defecto para las sesiones de navegador; si la desactivas para APIs, combínala con protecciones alternativas) y regenera la sesión al iniciar sesión.
8. SSRF y peticiones del lado del servidor (P2)
- Las peticiones del lado del servidor a URL suministradas por el usuario deben restringir los destinos a una lista de permitidos y bloquear el alcance a IP internas / metadatos de la nube en el momento de conectar (→ qué es SSRF).
Verifica: ¿está tu Spring Boot realmente endurecido?
Construirlo no es el final — solo está hecho una vez que lo has comprobado. Estas son autoverificaciones defensivas contra tu propio entorno.
Actuator no expone endpoints sensibles
/actuator no expone env/heapdump, etc., y que está autenticado.Los errores no filtran información interna
La autorización se sostiene
Dependencias y cabeceras
La visión de este sitio: sobre una base endurecida, deciden las dependencias y la superficie
Spring es una base sólida, pero precisamente por estar tan extendido, el fallo de una librería de dependencia se propaga a todos de golpe. Log4Shell es el símbolo de esto, y la defensa central es menos un ajuste concreto que el hábito operativo de monitorear las dependencias con una máquina, juzgar por la versión en ejecución y parchear rápido. Junto a eso, mantén los cómodos endpoints de gestión (Actuator) fuera de la superficie pública y no dejes la autorización a los valores por defecto. Este sitio usa una pila distinta, pero el principio es idéntico — la frescura de las dependencias, la mínima superficie pública y la autorización explícita funcionan sea cual sea el framework.
Sigue leyendo
- Centro: seguridad por framework · seguridad de Next.js
- Caso/práctica: la disección de Log4Shell · el manual de respuesta a vulnerabilidades · monitorear los CVE de dependencias
- Glosario: qué es IDOR · qué es RCE · qué es SSRF
- Herramientas: verificador de cabeceras de seguridad
FAQ
Q¿Qué debo hacer primero para asegurar Spring Boot?
Los tres puntos P0: (1) monitorea con una máquina los CVE de dependencias y parchea rápido, juzgando por la versión en ejecución (con Log4Shell, una librería de base se propaga de golpe a muchas apps, así que mantenerse al día importa); (2) no expongas errores detallados (stack traces) en producción; (3) externaliza los secretos (información de conexión, claves) en lugar de escribirlos a mano en la configuración. Luego, avanza hacia la autorización con Spring Security y la reducción de la exposición de Actuator.
Q¿A qué debo prestar atención con Actuator?
Actuator proporciona endpoints de gestión para información de ejecución y diagnóstico, pero si se expone puede filtrar información interna y, según la configuración, convertirse en un trampolín para operaciones. En producción, restringe la exposición al mínimo (p. ej., solo health), exige autenticación y autorización, y mantenlo en un puerto separado / una frontera de red inalcanzable desde fuera. No expongas endpoints sensibles como env, heapdump o loggers.
Q¿Cómo me preparo para un fallo de dependencia como Log4Shell?
Log4Shell es el caso clásico del fallo de una librería de logging ampliamente heredada propagándose de golpe a muchas apps. La preparación central es monitorear con una máquina los CVE de dependencias y parchear rápido, juzgando por la versión en ejecución (osv-scanner, OWASP dependency-check, etc.) — decide por la versión realmente construida, no por la declaración de pom.xml/gradle. El mínimo privilegio y la segmentación de red también reducen el radio de impacto.
Q¿Cómo escribo la autorización de Spring Security de forma segura?
Inclina el valor por defecto hacia la denegación (solo pasa lo que permites explícitamente), no dependas únicamente de patrones de URL y usa autorización a nivel de método (@PreAuthorize, etc.) donde corresponda. Además del inicio de sesión (autenticación), implementa una comprobación de propietario de que el recurso objetivo pertenece de verdad al usuario. Los huecos de configuración se convierten en agujeros de escalada de privilegios, así que construye la autorización de forma explícita.
Q¿Por qué es peligrosa la deserialización insegura?
Restaurar datos no confiables mediante la deserialización nativa de Java puede, en las condiciones adecuadas, llevar a ejecución remota de código (RCE). No restaures datos de origen externo tal cual — verifica su procedencia y, donde haga falta, restríngelo a un formato seguro como JSON. Del mismo modo, no dejes que las plantillas o el lenguaje de expresiones (SpEL) evalúen la entrada del usuario.