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 mantenimiento continuo.
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 ── Mantenimiento continuo
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 afecta a muchas apps a la vez. Log4Shell es el ejemplo más conocido.
- 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 algún endpoint abierto a cualquiera
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 / abuso para operaciones no autorizadas).
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: céntrate en las dependencias y en exponer lo mínimo
Spring es un framework estable, pero precisamente por estar tan extendido, el fallo de una librería de dependencia afecta a muchas apps a la vez. Log4Shell es el ejemplo más conocido, y la defensa principal 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 internet y no dejes la autorización a los valores por defecto. Este sitio usa una pila distinta, pero el principio es el mismo: mantener las dependencias al día, exponer lo mínimo y hacer explícita la autorización 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
Fuentes y alcance
Estas fuentes primarias respaldan los ajustes, el alcance o las medidas anteriores; enlaces comprobados el 23 de octubre de 2026. Revisa sus condiciones de versión y configuración. Las prioridades y lecciones son recomendaciones del sitio, no una revalidación completa ni una garantía de seguridad.