Saltar al contenido
← Volver al blog

Actuator /env: qué cambia al habilitar show-values

Corrección: Spring Boot 3+ oculta los valores por defecto. La revisión debe partir de la versión y la configuración efectiva de show-values.

11 de septiembre de 2026 · 2 min de lectura · 13 lecturas

  • #spring-boot
  • #java
  • #actuator
  • #spring-security

Corrección del 16 de septiembre de 2026. La versión anterior afirmaba que nombres como DB_PASS quedaban expuestos por defecto. Esa afirmación era incorrecta para Spring Boot 3+. También retiramos el ejemplo Java: no se había validado su compilación.

El punto de partida correcto

En Spring Boot 3.2.6, los valores de /env y /configprops están sanitizados por defecto. No corresponde deducir una fuga por el nombre de una variable. La referencia versionada de Actuator documenta ese comportamiento.

La referencia actual distingue tres opciones de show-values: never mantiene los valores ocultos; always permite mostrarlos; when-authorized los muestra a usuarios autorizados. Las funciones de sanitización personalizadas siguen pudiendo ocultarlos. Para HTTP, también importa la configuración de roles.

Qué revisaría antes de cambiarlo

Mi criterio es empezar por la necesidad de diagnóstico, no por escribir un regex. Si sólo necesito saber si una propiedad existe o de dónde viene, pedir acceso a todos sus valores puede ser innecesario.

  1. Registrar la versión exacta de Spring Boot y consultar su referencia.
  2. Revisar la configuración efectiva por ambiente, incluidos los overrides.
  3. Separar exposición del endpoint, autorización de acceso y visibilidad de valores.
  4. Probar con valores ficticios, sin credenciales reales, y con usuarios de distintos permisos.
  5. Registrar el resultado esperado y observado antes de ampliar el acceso.

Esto es un procedimiento propuesto, no un experimento ejecutado en este artículo. No demuestra cómo está configurada tu aplicación.

El límite de esta recomendación

Mantener valores ocultos no convierte cualquier exposición de Actuator en una buena decisión. Primero definiría quién necesita el endpoint, desde dónde y para resolver qué problema. Después probaría el caso concreto.

El error del artículo original fue presentar un comportamiento sin fijar versión y citar una documentación que no sostenía la afirmación. La corrección útil es revisar el contrato real del framework antes de proponer una defensa adicional.

¿Buscás este enfoque para tu equipo?

Conocé mis casos técnicos o conversemos sobre un rol senior, arquitectura y liderazgo técnico.

Comentarios (0)

¿Qué pensás de esto?

Dejá tu comentario en 10 segundos.

Usamos tu login solo para mostrar tu nombre y avatar. Nada de spam.

Todavía nadie comentó. Sé el primero — tu opinión vale oro cuando somos pocos.

Artículos Relacionados