SpringBootActuator安全防护全攻略

Spring Boot Actuator 是一把威力巨大的双刃剑：它默认仅暴露 health 和 info 端点看似安全，但一旦配置不慎（如误用 `include=*`、忽略 `show-details` 泄露风险、未为 `/actuator/**` 单独配置 Spring Security 链），就可能让数据库密码、内存堆栈、线程快照等敏感信息裸奔于公网；更隐蔽的是，K8s 探针、监控平台甚至 Basic Auth 本身都无法兜底——真正的防护必须层层设防：精确暴露必要端点、裁剪响应内容、隔离路径认证、禁用高危操作（如 env 值展示和 loggers 写入）、并绕过基础设施“假安全”陷阱。Actuator 的安全不是开与关的选择题，而是从配置、代码、网络到运行时的全链路守门战。

Actuator端点默认暴露哪些？不配置就等于裸奔

Spring Boot 2.x 默认只暴露 health 和 info 两个端点，其他如 env、beans、metrics、threaddump 等全被关在门外——但这是“不暴露”，不是“不可访问”。一旦你显式配置了 management.endpoints.web.exposure.include=* 或漏写了具体列表，所有端点立刻可被公网请求直达。

常见错误现象：本地调试时加了 include=*，上线忘记删；或用 Docker 部署时，配置文件混用了 dev profile；又或者以为加了 Spring Security 就万事大吉，结果没配匹配规则，/actuator/ 下所有路径仍可匿名访问。

• 检查 application.yml 中是否含 management.endpoints.web.exposure.include，禁止用 *，应明确列出需要的端点，例如：include: health,info,metrics,threaddump
• management.endpoint.health.show-details 默认为 never，若设为 always，会直接泄露数据库连接、配置属性等敏感字段，生产环境必须设为 when_authorized
• 即使只暴露 health，若未配 Spring Security，攻击者仍能通过 /actuator/health 探测服务存活、堆栈（如返回 UP 或 DOWN）甚至触发自定义健康检查逻辑中的副作用

Spring Security怎么拦住/actuator/**却不挡正常接口

Actuator 端点走的是独立的 WebMvc 路由（/actuator/xxx），和业务接口（如 /api/user）不在同一套拦截链里。只配 http.authorizeHttpRequests() 拦 /api/**，对 Actuator 完全无效。

关键点在于：Actuator 的安全控制必须显式声明匹配其路径前缀，并且要确保 SecurityFilterChain 生效顺序正确（不能被其他链覆盖）。

• 在配置类中定义独立的 SecurityFilterChain，专门处理 /actuator/**，例如：

  @Bean
  public SecurityFilterChain actuatorSecurityFilterChain(HttpSecurity http) throws Exception {
      http.requestMatcher(new AntPathRequestMatcher("/actuator/**"))
          .authorizeHttpRequests(authz -> authz
              .requestMatchers("/actuator/health").permitAll()
              .requestMatchers("/actuator/**").authenticated()
          );
      return http.build();
  }

• 避免用 .requestMatchers("/**") 通配兜底，否则会把 Actuator 请求也纳入主链，导致权限策略错乱
• 如果用了 Actuator 的 base-path 自定义（如 management.endpoints.web.base-path=/manage），Security 配置里的路径必须同步改成 /manage/**

为什么加了Basic Auth还是被扫出敏感信息？

Basic Auth 只是传输层身份校验，它不阻止响应体里包含不该有的数据。比如 /actuator/env 返回整个 Environment，里面可能有数据库密码、密钥、内部地址——这些不是认证问题，是端点本身设计如此。

更隐蔽的风险：某些端点（如 loggers）允许 POST 修改日志级别，攻击者可在未授权情况下调用 POST /actuator/loggers/root 把日志调成 DEBUG，间接拖垮服务或泄露更多上下文。

• 禁用高危端点比加固它们更可靠：在 application.yml 中设 management.endpoint.env.show-values: never（Spring Boot 3.2+）或直接移除 env 端点（exclude: env）
• loggers 端点默认开放 GET，但 POST 必须鉴权——需确认 Spring Security 是否已对 POST /actuator/loggers/** 做了 authenticated() 限制
• 不要依赖前端 Nginx 做“隐藏”：Nginx deny /actuator/env 只是挡住 HTTP 请求，如果应用自身有漏洞（如表达式注入、JNDI 反序列化），绕过 Nginx 直连应用端口仍可能触发端点逻辑

Actuator + Cloud Native 场景下容易忽略的细节

K8s liveness/readiness probe 如果直指 /actuator/health，而该端点又没做隔离，就会让 kubelet 成为“合法扫描器”——它每 10 秒一次 GET，持续暴露健康检查细节，尤其当 show-details=always 时，等于定时广播内部状态。

另一个坑是 Spring Boot Admin 类监控平台：它通常以客户端身份拉取所有端点数据，一旦 Admin Server 被攻破，所有受管应用的 metrics、threaddump、heapdump 都可能被批量导出。

• K8s probe 应单独配一个轻量级健康端点（如用 @RestController 写个 /healthz），不走 Actuator，也不读任何敏感属性
• 若必须用 Actuator，probe 路径设为 /actuator/health/liveness 并确保该 group 不返回详情（management.endpoint.health.probes.show-details=never）
• Spring Boot Admin 客户端与服务端之间务必启用 HTTPS + 双向 TLS，且 Admin Server 的访问 IP 必须白名单限制，不能放行整个内网段

Actuator 的安全水位线不在“能不能打开”，而在“打开之后，哪一层还在守门”。路径匹配、响应裁剪、网络边界、调用方身份——少守一环，就等于把钥匙放在门口鞋垫下。

好了，本文到此结束，带大家了解了《SpringBootActuator安全防护全攻略》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！