Spring Boot 2.x默认仅暴露health和info端点；其他端点需显式配置exposure.include才启用，禁用通配符，应明确列出所需端点并配合Spring Security单独配置/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 的安全水位线不在“能不能打开”，而在“打开之后，哪一层还在守门”。路径匹配、响应裁剪、网络边界、调用方身份——少守一环，就等于把钥匙放在门口鞋垫下。
