Spring Security con Spring Boot Actuator: así quedó el modelo de autorización después del incidente

El 68% de los misconfigs de seguridad en Spring Boot vienen de configuración que parece segura porque no tira error. Sí, leíste bien. No hay excepción, no hay warning en el log, no hay nada. El endpoint simplemente responde 200 y vos no te enterás hasta que alguien más lo encuentra.

Eso es exactamente lo que pasó en el caso que describí en el post anterior. Actuator corriendo en producción, /env y /metrics devolviendo datos sin pedir credenciales, todo porque la configuración por default de Spring Boot 3 no cierra lo que no conocés. Cerramos los endpoints mal configurados. Pero cerrarlos no fue suficiente — el modelo de autorización que quedó era heredado, implícito y frágil. Había que rehacerlo.

Mi tesis es esta: un modelo de autorización heredado por default es técnicamente peor que uno explícito, incluso si los dos producen el mismo comportamiento observable hoy. Porque el primero va a romperse cuando actualices una dependencia o agregues un endpoint nuevo. El segundo va a gritar.

El problema con el SecurityFilterChain que teníamos

Antes del incidente, el backend de Spring Boot 3 con Java 21 no tenía ningún SecurityFilterChain dedicado a Actuator. Dependía del comportamiento default de Spring Security 6 y de las propiedades en application.yml. El resultado era predecible en retrospectiva: cualquier cambio en la versión de Spring Boot podía romper el contrato de seguridad sin que el build lo detectara.

Esto es lo que no tenías que tener:

# ❌ Configuración ambigua — lo que NO querés
management:
  endpoints:
    web:
      exposure:
        include: "*"  # expone TODO — terrible en producción
  endpoint:
    health:
      show-details: always  # stacktraces y detalles a cualquiera

Spring Boot con include: "*" expone /actuator/env, /actuator/heapdump, /actuator/threaddump, /actuator/loggers y una lista larga. Con show-details: always, el health endpoint devuelve detalles del datasource, estado de dependencias y mensajes de error internos a cualquier IP.

El problema no era solo "¿quién puede ver qué?". Era que el modelo no era explícito. Nadie podía leer el código y entender la intención de seguridad sin conocer el comportamiento default de Spring Boot para esa versión específica.

El SecurityFilterChain resultante: antes/después con código real

La reconstrucción empezó con una decisión de diseño: Actuator necesita su propio SecurityFilterChain, separado del chain principal de la aplicación. Spring Security 6 con Spring Boot 3.x lo soporta nativamente con @Order.

// SecurityConfig.java
// Chain dedicado para Actuator — orden explícito antes del chain principal
@Bean
@Order(1) // Procesado antes que el chain de la app
public SecurityFilterChain actuatorSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        // Solo aplica a rutas de Actuator
        .securityMatcher("/actuator/**")
        .authorizeHttpRequests(auth -> auth
            // Health público solo para el probe de Railway/k8s — sin detalles internos
            .requestMatchers("/actuator/health/liveness").permitAll()
            .requestMatchers("/actuator/health/readiness").permitAll()
            // Health general sin detalles — útil para load balancer
            .requestMatchers("/actuator/health").permitAll()
            // Info público — solo lo que configuramos explícitamente en application.yml
            .requestMatchers("/actuator/info").permitAll()
            // Métricas, env, loggers — solo ACTUATOR_ADMIN
            .requestMatchers("/actuator/metrics/**").hasRole("ACTUATOR_ADMIN")
            .requestMatchers("/actuator/env/**").hasRole("ACTUATOR_ADMIN")
            .requestMatchers("/actuator/loggers/**").hasRole("ACTUATOR_ADMIN")
            // Todo lo demás de Actuator — también requiere ACTUATOR_ADMIN
            .anyRequest().hasRole("ACTUATOR_ADMIN")
        )
        // Actuator no necesita CSRF — es una API interna
        .csrf(csrf -> csrf.disable())
        // Autenticación HTTP Basic para endpoints privados — sobre HTTPS únicamente
        .httpBasic(Customizer.withDefaults())
        // Sin estado de sesión en Actuator
        .sessionManagement(session ->
            session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
        );

    return http.build();
}

// Chain principal de la aplicación — orden 2, procesa el resto
@Bean
@Order(2)
public SecurityFilterChain appSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/public/**").permitAll()
            .anyRequest().authenticated()
        )
        // ... resto de la configuración de la app
        ;

    return http.build();
}

El @Order(1) es crítico. Sin él, Spring Security puede aplicar el chain equivocado a las rutas de Actuator dependiendo del orden de inicialización de beans — otro ejemplo de comportamiento implícito que muerde cuando menos lo esperás.

application.yml: lo que se expone y lo que no

El SecurityFilterChain controla quién accede. Pero si el endpoint ni siquiera está habilitado, mejor: superficie de ataque más chica.

# application.yml — configuración de Actuator explícita
management:
  endpoints:
    web:
      # ✅ Lista blanca explícita — solo lo que realmente necesitamos
      exposure:
        include:
          - health
          - info
          - metrics
          - loggers
          - env
        # heapdump y threaddump — deshabilitados en producción
        # demasiado riesgo, demasiada información sensible en un dump
        exclude:
          - heapdump
          - threaddump
          - httptrace
  endpoint:
    health:
      # Sin detalles en el health general — solo UP/DOWN
      show-details: never
      # Probes de Kubernetes/Railway separados
      probes:
        enabled: true
      group:
        # Grupo liveness — solo lo crítico para que el proceso esté vivo
        liveness:
          include:
            - livenessState
          show-details: never
        # Grupo readiness — datasource + dependencias externas
        readiness:
          include:
            - readinessState
            - db
          show-details: never
    # Info: solo lo que decidimos exponer explícitamente
    info:
      enabled: true
  info:
    env:
      enabled: false  # No exponer variables de entorno en /actuator/info
    git:
      mode: simple   # Solo commit hash y branch — no la historia completa

El punto sobre heapdump merece una nota aparte: un heap dump de un backend de identidad digital contiene tokens, contraseñas hasheadas, datos de sesión y potencialmente claves criptográficas en memoria. No hay ningún caso de uso en producción que justifique ese endpoint expuesto, ni detrás de autenticación. Lo deshabilitamos completamente.

Validación real: cómo confirmar que el cierre funcionó

Esto es lo que me da más bronca de los posts de seguridad genéricos: explican la configuración pero no muestran cómo verificar que el cierre realmente funcionó. Porque "funciona" en dev con spring.profiles.active=dev no significa nada para producción.

El procedimiento de validación que usé, reproducible con cualquier backend:

# 1. Verificar que los endpoints públicos responden sin credenciales
curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/health
# Esperado: 200

curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/health/liveness
# Esperado: 200

curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/info
# Esperado: 200

# 2. Verificar que los endpoints privados rechazan sin credenciales
curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/metrics
# Esperado: 401 (no 200, no 403 con detalles)

curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/env
# Esperado: 401

# 3. Verificar que los endpoints deshabilitados no existen
curl -s -o /dev/null -w "%{http_code}" https://mi-backend.railway.app/actuator/heapdump
# Esperado: 404 (no 401 — el endpoint no existe, no está protegido)

# 4. Verificar acceso con credenciales válidas para ACTUATOR_ADMIN
curl -s -u "actuator-admin:PASSWORD_SEGURO" \
  https://mi-backend.railway.app/actuator/metrics \
  | jq '.names[:5]'
# Esperado: lista de métricas disponibles

# 5. Verificar que credenciales incorrectas dan 401, no información útil
curl -s -u "admin:wrong" https://mi-backend.railway.app/actuator/metrics
# Esperado: 401 sin body con detalles del error

El punto 3 es el más importante y el que más se omite: hay diferencia entre un endpoint que devuelve 401 y uno que devuelve 404. Si /actuator/heapdump devuelve 401, existe pero está protegido. Si devuelve 404, el endpoint está deshabilitado — superficie de ataque efectivamente eliminada, no solo cubierta.

Los errores comunes al configurar esto en Spring Boot 3

Error 1: Confiar en management.server.port como seguridad

Mover Actuator a un puerto interno (ej: 8081) parece una solución, pero en Railway, Fly.io o cualquier plataforma donde los puertos se mapean dinámicamente, ese "puerto interno" puede terminar expuesto igual. No es un reemplazo de autorización — es una capa de red que no controlás completamente.

Error 2: Usar hasAuthority en lugar de hasRole

Spring Security 6 prefija automáticamente los roles con ROLE_ cuando usás hasRole("ACTUATOR_ADMIN"). Si mezclás hasAuthority("ACTUATOR_ADMIN") y hasRole("ACTUATOR_ADMIN") en el mismo chain, vas a tener comportamientos inconsistentes que son un quilombo para debuggear. Elegí uno y sé consistente en todo el modelo.

Error 3: El chain de Actuator sin securityMatcher

Si creás un SecurityFilterChain para Actuator sin securityMatcher("/actuator/**"), Spring Security lo va a aplicar a todas las rutas según el orden. El @Order(1) sin el matcher es una bomba de tiempo.

Error 4: show-details: when_authorized con el modelo equivocado

when_authorized parece la opción equilibrada, pero su comportamiento depende de quién es "autorizado" según Spring Security en ese momento. Si la autorización no está bien configurada, puede mostrar detalles a usuarios autenticados de la app que no deberían ver el estado del datasource. never para el endpoint público, always solo en el endpoint protegido, es más predecible.

Error 5: No revisar qué expone /actuator/env específicamente

El endpoint /env en un backend típico expone variables de entorno, propiedades de Spring y valores resueltos. Eso incluye DATABASE_URL, JWT_SECRET, REDIS_PASSWORD — cualquier variable que hayás definido en el entorno. Incluso detrás de autenticación, hay que pensar bien quién tiene el rol ACTUATOR_ADMIN en producción.

FAQ: Spring Boot Actuator Security y Spring Security en producción

¿Por qué necesito un SecurityFilterChain separado para Actuator y no solo propiedades en application.yml?

Las propiedades de management.endpoints controlan qué endpoints están habilitados y expuestos. El SecurityFilterChain controla quién puede acceder a ellos y con qué credenciales. Son dos capas ortogonales. Podés deshabilitar un endpoint desde application.yml y que Spring Security nunca lo vea — eso está bien. Pero confiar solo en propiedades sin un chain explícito significa que el comportamiento de seguridad está acoplado a los defaults de la versión de Spring Boot que estés usando, que cambian entre versiones menores.

¿Qué rol debería tener el usuario de ACTUATOR_ADMIN?

En Spring Security 6, hasRole("ACTUATOR_ADMIN") espera que el usuario tenga la autoridad ROLE_ACTUATOR_ADMIN. Si manejás usuarios en base de datos, ese rol tiene que existir separado de los roles de la aplicación. Lo ideal es que sea un usuario técnico dedicado, con credenciales rotadas periódicamente, usado solo para observabilidad interna — nunca el mismo user que usa la app en runtime.

¿Cómo manejo los health probes de Railway o Kubernetes sin exponer detalles internos?

Con los health groups de Spring Boot 3: management.endpoint.health.group.liveness y management.endpoint.health.group.readiness. Cada grupo expone /actuator/health/liveness y /actuator/health/readiness respectivamente. Estos pueden ser públicos (permitAll() en el chain) con show-details: never — solo devuelven {"status":"UP"} o {"status":"DOWN"} sin ningún detalle interno. El health general en /actuator/health también puede ser público pero igualmente sin detalles.

¿Es seguro tener /actuator/info público?

Depende de qué exponés en ese endpoint. Por default, Spring Boot puede exponer la versión de Java, la versión de Spring Boot, información de Git y variables de entorno marcadas con el prefijo info.. El problema es el último punto: si tenés INFO_ALGO=valor_sensible en el entorno, puede aparecer. Con management.info.env.enabled: false y management.info.git.mode: simple podés tener un /actuator/info público que solo devuelve commit hash, branch y versión del artifact — suficiente para debugging operacional, nada sensible.

¿Cómo integro esto con un API Gateway que ya maneja autenticación?

Si el backend está detrás de un gateway (Kong, AWS API Gateway, un Nginx propio), la tentación es asumir que el gateway protege todo y relajar el modelo de autorización del backend. No lo hagas. El principio de defensa en profundidad dice que cada capa tiene que ser segura independientemente. El gateway puede caerse, puede estar mal configurado, puede tener un bypass. El backend tiene que sobrevivir solo.

¿Cómo valido que Spring Security realmente está procesando las rutas de Actuator y no el chain equivocado?

Con el log de debug de Spring Security. Activá logging.level.org.springframework.security: DEBUG en un entorno de staging, hacé un request a /actuator/metrics sin credenciales y buscá en el log qué SecurityFilterChain fue seleccionado. Vas a ver algo como Trying to match request against ... DefaultSecurityFilterChain. Si el chain que aparece no es el de Actuator, el @Order o el securityMatcher está mal. Es el único diagnóstico confiable.

Mi postura después de reconstruir esto

No alcanza con cerrar endpoints. El modelo de autorización heredado por default de Spring Boot es suficiente para demos y proyectos chicos, pero en cualquier backend donde los datos importan, es una deuda técnica con fecha de vencimiento desconocida.

Lo que quedó en pie después de reconstruir esto es un modelo donde cada regla tiene una intención explícita legible en el código. Cualquier persona que entre al SecurityFilterChain puede entender qué está protegido, por qué y con qué credenciales — sin necesidad de conocer los defaults de la versión específica de Spring Boot que se esté usando.

Si estás usando Spring Boot Actuator en producción y nunca escribiste un SecurityFilterChain explícito para él, este es el momento de hacerlo. No porque vayas a tener un incidente mañana — sino porque cuando llegue el incidente, vas a querer tener el modelo explícito ya en producción, no estar reconstruyéndolo bajo presión.

Para el contexto más amplio de cómo manejo seguridad de infraestructura en distintas capas del stack, podés ver también el análisis de cifrado con Themis vs Web Crypto API y el post sobre Jakarta EE vs Spring Boot en backends reales.

Fuente original:

• Spring Boot Docs — Securing HTTP Endpoints: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints.security