SpringBoot Actuator未授权访问漏洞：原理、检测与防护实战指南

原创于 2026-06-25 12:17:52 发布 · 161 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#SpringBoot Actuator #未授权访问 #端点安全

1. 项目概述：为什么SpringBoot未授权访问是“沉默的杀手”？

干了这么多年安全，我见过太多因为一个看似不起眼的配置疏忽，导致整个系统被“扒光”的案例。SpringBoot未授权访问漏洞，绝对是其中的典型代表。它不像SQL注入、XSS那样需要复杂的攻击载荷，也不像RCE（远程代码执行）那样动静巨大。它更像是一扇忘了上锁的后门，攻击者大摇大摆走进来，查看你的应用配置、监控数据、甚至执行管理命令，而你却可能毫无察觉。

这个漏洞的核心，源于SpringBoot强大的“约定大于配置”理念。为了提升开发效率，SpringBoot内置了大量开箱即用的端点（Actuator Endpoints），用于应用监控和管理。比如 /actuator/health 用来检查健康状态， /actuator/metrics 用来查看性能指标， /actuator/env 能暴露全部环境变量（可能包含数据库密码、API密钥）。在开发阶段，这些端点非常方便。问题在于，如果项目上线时，没有对这些管理端点施加严格的访问控制，它们就会直接暴露在公网。攻击者无需任何认证，访问对应的URL路径，就能直接获取敏感信息或执行操作。

更棘手的是，这种漏洞的利用门槛极低。攻击者不需要掌握高深的漏洞利用技术，只需要一个浏览器或者简单的curl命令，就能完成一次“漫步式”的信息搜集。从暴露的env端点找到数据库连接字符串，从heapdump端点下载内存转储文件并离线分析寻找敏感信息，甚至通过 /actuator/loggers 端点动态修改日志级别来绕过某些日志审计。整个过程安静、高效，往往在数据已经泄露之后，我们才发现日志里多了许多来自奇怪IP的、对 /actuator/* 路径的访问记录。

因此，针对SpringBoot未授权访问的检测与防护，不是一项可做可不做的“加分项”，而是保障SpringBoot应用上线安全的“必修课”。本指南将从一个实战攻防的角度，带你完整走一遍从漏洞发现、风险验证到彻底加固的全过程，分享那些在官方文档里不会写的排查技巧和防护心得。

2. 漏洞原理深度剖析：端点暴露与权限缺失的双重陷阱

要有效防护，必须先透彻理解漏洞产生的根源。SpringBoot未授权访问漏洞的形成，主要踩中了两个“坑”：一是端点的无意暴露，二是访问控制的完全缺失。

2.1 Actuator端点：一把锋利的双刃剑

SpringBoot Actuator模块的设计初衷是好的，它提供了一系列生产就绪的特性，帮助运维人员监控和管理应用。其核心是众多的“端点”。你可以把这些端点理解为应用内部一个个特殊的“数据接口”或“控制面板”。

默认情况下，在SpringBoot 2.x中，出于安全考虑，只有 /actuator/health 和 /actuator/info 端点是默认开启并对外暴露的（通过HTTP）。然而，“暴露”的定义很关键。这里的“开启”指的是端点功能可用，而“暴露”指的是通过哪种协议（如HTTP或JMX）可以访问到它。通过配置 management.endpoints.web.exposure.include 属性，开发者可以轻松地将更多端点通过HTTP暴露出来。

常见的危险端点包括：

/actuator/env (或 /env ，旧版本)： 最危险端点之一 。泄露所有环境属性，包括 application.properties/yml 中的配置、系统环境变量、命令行参数。数据库密码、Redis密码、第三方API密钥在这里一览无余。
/actuator/heapdump (或 /heapdump ): 生成一个JVM堆转储文件（HPROF格式）。攻击者下载后，可以使用MAT、VisualVM等工具进行离线分析，从中查找内存中的敏感字符串，如密码、会话令牌等。
/actuator/mappings (或 /mappings ): 显示所有 @RequestMapping 路径。相当于给攻击者提供了一份完整的应用API地图，有助于其发现其他潜在的攻击面。
/actuator/loggers : 允许动态查看和修改运行时日志级别。攻击者可以将特定包的日志级别调整为DEBUG，试图让应用打印出更多敏感信息。
/actuator/threaddump : 获取当前线程快照。虽然直接危害较小，但结合其他信息，可用于分析应用状态。
/actuator/beans (或 /beans ): 显示应用中所有的Spring Bean定义。可能泄露内部业务逻辑结构。

配置失误的典型场景： 很多开发者为了图方便，或者从网上拷贝了配置片段，会在 application.yml 中写下这样的配置：

management:
  endpoints:
    web:
      exposure:
        include: "*" # 暴露所有端点
  endpoint:
    health:
      show-details: always # 健康端点显示全部细节

这一行 include: "*" ，就等于把上面所有危险端点的门都打开了。更糟糕的是，有些旧的教程或项目（基于SpringBoot 1.x）可能直接通过 endpoints.*.enabled=true 来开启端点，在2.x版本下这可能会引发意料之外的暴露行为。

2.2 权限控制的完全缺失：没有守门人的仓库

端点暴露只是第一步，让漏洞真正成立的关键是 没有配置任何访问控制 。SpringBoot Actuator端点本身不提供认证和授权机制。它依赖于Web应用的安全框架，比如Spring Security。

如果一个SpringBoot应用引入了Actuator但没有引入Spring Security，或者引入了Spring Security但没有为Actuator端点配置任何安全规则，那么这些端点就会处于“裸奔”状态。任何能够访问到应用IP和端口的人，都可以直接调用这些端点。

这里有一个非常重要的认知误区： 很多开发者认为，只要不把 /actuator 这个路径映射到外网网关或者负载均衡器上，内网访问就是安全的。这就是典型的“内网绝对安全”假设，在当今的攻击手段下非常危险。一旦攻击者通过其他方式（如钓鱼、漏洞利用）进入了内网，或者存在内部威胁，这些未防护的端点就是唾手可得的宝藏。

实操心得： 永远不要依赖“网络位置”作为唯一的安全边界。安全设计必须遵循“最小权限原则”和“纵深防御原则”。即使在内网，对管理接口进行认证和授权也是必须的。

3. 实战检测三部曲：从信息搜集到漏洞验证

知道了原理，我们该如何主动发现自身应用是否存在这类漏洞呢？下面这套“三步走”的检测流程，是我在内部渗透测试和红蓝对抗中常用的方法，兼具系统性和可操作性。

3.1 第一步：资产发现与端点枚举

在测试之前，你首先得知道目标是什么。对于SpringBoot应用，识别其特征和可能的端点路径是第一步。

1. 应用指纹识别： SpringBoot应用有一些常见的特征，可以帮助我们快速识别：

默认错误页面： 访问一个不存在的路径，SpringBoot默认的错误页面通常会包含 Whitelabel Error Page 字样，并带有 timestamp 、 status 、 error 、 message 等字段的JSON结构。这在HTTP响应体或页脚中可能看到。
特定HTTP头： 有些版本可能会在HTTP响应头中携带 X-Application-Context 字段。
默认端口： 虽然不绝对，但嵌入式Tomcat的SpringBoot应用常运行在8080端口。

你可以使用浏览器开发者工具、 curl 命令或Burp Suite等代理工具来观察响应。

2. 端点路径枚举： 识别出可能是SpringBoot应用后，开始系统性地枚举Actuator端点。不要只尝试 /actuator 这一个路径。

常见路径列表： 准备一个包含常见端点路径的字典文件进行扫描。例如：

/actuator
/actuator/health
/actuator/info
/actuator/env
/actuator/heapdump
/actuator/mappings
/actuator/loggers
/actuator/beans
/actuator/threaddump
/actuator/metrics
/actuator/conditions
/actuator/configprops
/actuator/scheduledtasks

注意历史路径： SpringBoot 1.x的端点路径没有 /actuator 前缀，直接是 /env ， /health 等。所以对 /env ， /metrics 等根路径的扫描同样重要。
使用工具自动化： 可以使用 dirsearch ， gobuster ， ffuf 等目录爆破工具，载入针对SpringBoot的专用字典进行扫描，效率远高于手动尝试。
```
# 使用ffuf进行快速枚举示例
ffuf -w springboot_endpoints.txt -u http://target:8080/FUZZ -mc 200
```

3.2 第二步：漏洞验证与信息提取

当扫描器返回了状态码为200（或2xx）的端点路径时，真正的验证就开始了。你需要手动访问这些端点，评估其风险等级。

1. 访问验证： 直接使用浏览器或 curl 访问疑似端点。

curl -v http://target:8080/actuator/env

如果返回了包含 "propertySources" 等大量配置信息的JSON，那么 /actuator/env 端点就是未授权且暴露的。

2. 风险信息提取： 对于不同的端点，关注的信息点不同：

/actuator/env : 重点搜索 password ， secret ， key ， token ， url ， jdbc 等关键词。数据库连接串、云服务AccessKey、加密密钥都可能在这里。
/actuator/mappings : 查看所有接口路径，寻找可能未授权的API、上传接口、管理接口等。
/actuator/health : 如果配置了 show-details: always ，可能会暴露磁盘状态、数据库状态等细节。
/actuator/configprops : 查看所有 @ConfigurationProperties 的配置，可能包含业务敏感配置。

3. 高风险操作验证（谨慎！）：

/actuator/loggers : 尝试发送一个POST请求，修改某个包的日志级别为 DEBUG 。
```
curl -X POST http://target:8080/actuator/loggers/com.example.demo \
     -H "Content-Type: application/json" \
     -d '{"configuredLevel":"DEBUG"}'
```
如果返回200，说明可以动态修改日志，可能用于信息泄露。
/actuator/heapdump : 尝试访问，如果浏览器开始下载一个 .hprof 文件，说明此端点开放。 注意： 生成堆转储会对服务端性能产生瞬时影响，在生产环境测试需谨慎，最好在测试环境进行。

3.3 第三步：利用工具进行自动化评估

手动检测虽然精准，但效率低。我们可以借助一些优秀的开源工具进行半自动化或自动化的漏洞检测与利用。

1. SpringBoot-Actuator-Exploit 类工具： 网络上存在一些针对此漏洞的利用工具（如某些Python脚本），它们能自动枚举端点，并从 env ， configprops 等端点中自动提取密码、密钥等敏感信息。 在使用任何第三方利用工具时，必须注意：

仅用于授权测试！ 在法律和授权范围内使用。
审查工具代码！ 避免工具本身含有恶意代码。
理解其原理！ 工具只是辅助，明白它在做什么更重要。

2. 集成到漏洞扫描器： 许多商业或开源的Web漏洞扫描器（如AWVS， Nessus， Xray， Nuclei）都已经内置了SpringBoot Actuator未授权访问的检测插件（POC）。

特别是 Nuclei ，社区提供了大量高质量的模板。你可以很容易地找到针对不同SpringBoot端点的检测模板。使用Nuclei进行批量资产扫描，是当前非常高效的方式。

nuclei -u http://target:8080 -t /path/to/springboot-actuator-templates/

注意事项： 自动化工具可能会产生大量请求，对目标服务造成压力。在测试生产系统时，务必控制扫描速率，并在业务低峰期进行，最好提前与运维团队沟通。

4. 分级防护策略：从紧急处置到架构免疫

检测出漏洞后，如何修复和防护？我建议采取分级、递进的策略，从最紧急的“止血”措施，到中期的安全加固，再到长期的架构免疫。

4.1 紧急处置（立即执行）

如果发现生产环境存在未授权访问，应立即采取以下措施：

1. 修改配置，关闭端点暴露（最快）： 这是最直接的“止血”方法。修改应用的 application.yml 或 application.properties ，将暴露的端点范围缩到最小。

management:
  endpoints:
    web:
      exposure:
        include: "health,info" # 只暴露健康和基本信息端点
        # exclude: "*" # 或者使用排除法，排除所有，再单独包含需要的
  endpoint:
    health:
      show-details: when-authorized # 仅在授权时显示详情

修改后必须重启应用生效。 同时，检查所有配置文件（包括bootstrap.yml，以及通过 --spring.config.location 指定的外部配置），确保没有其他位置覆盖了此安全配置。

2. 网络层访问控制（临时隔离）： 如果无法立即重启应用，可以通过网络防火墙、安全组、WAF（Web应用防火墙）等设备，在网络层对访问 /actuator/* 路径的流量进行拦截。例如，配置安全组规则，只允许运维堡垒机的IP访问应用的管理端口。这是一种临时但有效的隔离手段。

4.2 安全加固（中期方案）

紧急处置后，需要实施更稳固的安全加固，防止配置被意外改回。

1. 引入Spring Security并配置细粒度权限： 这是 最根本、最推荐的解决方案 。

添加依赖： 在 pom.xml 或 build.gradle 中引入Spring Security依赖。

配置安全规则： 创建一个Security配置类，为Actuator端点配置严格的访问控制。通常，我们会要求所有Actuator端点都需要认证，并且只有拥有特定角色（如


   ADMIN

，


   ACTUATOR

）的用户才能访问。

import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
public class ActuatorSecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authz -> authz
                // 对所有Actuator端点，要求拥有ACTUATOR_ADMIN角色
                .requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ACTUATOR_ADMIN")
                // 对其他公共API，可以配置不同的规则
                .requestMatchers("/api/public/**").permitAll()
                // 默认所有请求都需要认证
                .anyRequest().authenticated()
            )
            .httpBasic(); // 使用HTTP Basic认证，生产环境建议用更安全的如JWT
        return http.build();
    }

    @Bean
    public UserDetailsService userDetailsService(PasswordEncoder passwordEncoder) {
        UserDetails actuatorUser = User.builder()
                .username("actuatorAdmin")
                .password(passwordEncoder.encode("StrongPassword123!")) // 务必使用强密码
                .roles("ACTUATOR_ADMIN")
                .build();
        return new InMemoryUserDetailsManager(actuatorUser);
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

关键点：

使用 EndpointRequest.toAnyEndpoint() 来匹配所有Actuator端点，比手动写路径前缀更准确、更未来兼容。
绝对不要使用明文密码！ 示例中的 passwordEncoder 是必须的。
InMemoryUserDetailsManager 仅适用于演示或简单场景。生产环境必须集成LDAP、数据库或统一的SSO认证系统。

2. 自定义端点路径与管理上下文： 通过修改默认的端点路径和管理上下文，可以增加攻击者的猜测难度，但这只是一种“安全通过隐匿”（Security by Obscurity）的辅助手段， 绝不能替代认证授权 。

management:
  endpoints:
    web:
      base-path: "/manage" # 将默认的 /actuator 改为 /manage
      exposure:
        include: "health,info"
  server:
    port: 9090 # 将管理端点发布到独立的端口（需要SpringBoot 2.x+）

将管理端口（如9090）与业务端口（如8080）分离，并在网络层面严格限制对管理端口的访问（仅限运维网段），可以实现更好的网络隔离。

4.3 架构免疫与最佳实践（长期建设）

要从根本上降低风险，需要将安全思维融入开发和运维的整个生命周期。

1. 安全配置基线化： 将安全的Actuator配置作为所有SpringBoot项目的 初始化模板或脚手架的一部分 。在项目创建之初，就包含正确的Spring Security依赖和配置类，避免开发者从头开始写或从网上拷贝不安全的配置。

2. CI/CD流水线集成安全扫描： 在代码构建和部署流水线中，集成静态应用安全测试（SAST）和软件成分分析（SCA）工具。虽然它们可能无法直接发现运行时配置错误，但可以检查 application.yml 中是否存在 include: "*" 这样的危险模式。同时，可以使用OWASP Dependency-Check检查项目依赖（包括Actuator）是否存在已知漏洞。

3. 生产环境配置与开发环境隔离： 使用Spring的Profile功能，严格区分开发、测试、生产环境的配置。

# application-dev.yml (开发环境)
management:
  endpoints:
    web:
      exposure:
        include: "*" # 开发环境为了方便调试，可以暴露更多
  endpoint:
    health:
      show-details: always

# application-prod.yml (生产环境)
management:
  endpoints:
    web:
      exposure:
        include: "health"
  endpoint:
    health:
      show-details: never # 生产环境不显示详情

通过启动参数 --spring.profiles.active=prod 来激活生产环境配置。

4. 定期安全审计与渗透测试： 建立定期的安全审计机制，使用本指南提到的检测方法，对线上应用进行主动扫描。同时，聘请专业的安全团队或通过内部红队进行定期的渗透测试，模拟真实攻击，发现包括未授权访问在内的各类安全漏洞。

5. 进阶场景与疑难排查

在实际环境中，情况可能比基础场景更复杂。这里分享几个进阶场景的处理思路和排查技巧。

5.1 网关与路由场景下的防护

在现代微服务架构中，SpringBoot应用通常不会直接对外暴露，而是通过API网关（如Spring Cloud Gateway， Zuul）或负载均衡器对外提供服务。这带来了新的防护点和风险点。

风险： 即使后端微服务正确配置了Actuator端点的Spring Security认证，如果网关到微服务的内网通信是可信的（未配置认证），那么攻击者一旦入侵网关服务器，或者网关本身存在未授权访问漏洞，就可以通过网关直接访问后端微服务的Actuator端点。

防护策略：

网关层统一认证： 在网关层对所有的管理路径（如 /actuator/** ， /admin/** ）进行拦截和认证。只有携带有效管理令牌或来自特定IP的请求才被路由到后端服务。
微服务间认证： 即使在服务网格内部，也建议启用服务间认证（如mTLS双向TLS认证），确保只有合法的服务才能相互通信。
网关路由配置审查： 仔细检查网关的路由配置，确保没有将后端服务的Actuator路径（如 /actuator/** ）暴露到外部路由规则中。通常，网关只应转发业务API路径。

5.2 第三方组件引发的端点泄露

除了SpringBoot Actuator，一些常用的第三方组件也可能引入类似的管理端点。

1. Swagger/OpenAPI： Swagger UI（ /swagger-ui.html ）和API文档端点（ /v2/api-docs ， /v3/api-docs ）如果未授权访问，会泄露所有API接口的详细信息，包括参数、路径，甚至可能包含接口的测试功能。 防护方法： 在生产环境通过Profile禁用Swagger，或为其配置与Actuator同样严格的Spring Security访问控制。

// 在Security配置中增加对Swagger路径的保护
.requestMatchers("/swagger-ui/**", "/v3/api-docs/**", "/swagger-resources/**").hasRole("ADMIN")

2. H2数据库控制台： 在SpringBoot中集成H2数据库时，如果启用了H2控制台（ spring.h2.console.enabled=true ），且未加保护，访问 /h2-console 可以直接操作数据库，执行任意SQL。 防护方法： 生产环境绝对不要开启H2控制台。如果开发测试需要，必须通过Spring Security限制访问源IP和用户认证。

3. 监控组件： 集成Prometheus， Grafana等监控系统时，对应的 /metrics ， /prometheus 端点或Grafana面板本身也需要施加访问控制。

排查技巧： 当你已经为 /actuator/** 配置了安全规则，但发现仍有未授权访问时，一定要检查应用是否引入了其他带有Web界面的组件，并检查这些组件的自动配置路径。使用 /actuator/mappings 端点（在授权后）可以清晰地看到应用所有已注册的HTTP路径，这是一个非常好的自查工具。

5.3 漏洞修复后的验证与监控

修复配置并重启服务后，如何验证漏洞确实被堵上了？

1. 验证方法：

未授权访问测试： 再次使用之前的检测方法（curl、浏览器、扫描器）尝试访问危险的Actuator端点（如 /actuator/env ）。此时应该收到 401 Unauthorized （如果配置了认证）或 404 Not Found （如果端点已被排除暴露）。
授权访问测试： 使用配置的正确用户名和密码（或Token）进行访问，确认授权用户可以正常访问必要的管理端点（如 /actuator/health ）。
```
curl -u actuatorAdmin:StrongPassword123! http://target:8080/actuator/health
```

2. 监控与告警：

日志监控： 在应用日志中，对访问Actuator端点的请求（尤其是认证失败 401 ）进行监控和告警。短时间内大量 401 请求可能代表有攻击者在进行爆破扫描。
WAF/IDS规则： 在Web应用防火墙或入侵检测系统中，可以添加规则，对访问常见Actuator端点路径（如 /env ， /heapdump ）的请求进行记录或阻断，无论其是否成功。
定期扫描： 将内部SpringBoot应用的Actuator端点扫描纳入定期的漏洞扫描任务中，确保没有新的服务因配置错误而引入风险。

6. 常见问题与排查技巧实录

在实际操作和应急响应中，总会遇到一些“奇怪”的问题。这里记录了几个典型案例和解决方法。

问题1：明明在配置里设置了 exposure.include=health,info ，为什么 /actuator/env 还能访问？

可能原因1：配置未生效。 检查配置文件是否被正确加载。是否有多个 application-{profile}.yml 文件？激活的Profile是什么？是否通过命令行参数 --management.endpoints.web.exposure.include=* 覆盖了配置文件？使用 /actuator/conditions 端点（如果可访问）可以查看配置的生效情况。
可能原因2：Spring Security配置有误。 检查Security配置类的规则顺序。Spring Security的规则是 从上到下匹配，首次匹配即生效 。如果有一条更通用的规则（如 .anyRequest().permitAll() ）放在了针对Actuator的规则前面，就会导致Actuator端点被意外放行。
排查技巧： 开启Spring Security的调试日志，可以清晰地看到每个请求是如何被安全过滤器链处理的。
```
logging:
  level:
    org.springframework.security: DEBUG
```

问题2：引入了Spring Security，但访问业务API也需要认证了，如何只保护管理端点？

解决方案： 这就是上面配置示例中使用的策略。使用 requestMatchers() 来精确匹配需要保护的路径（如 EndpointRequest.toAnyEndpoint() ），对于业务API路径（如 /api/public/** ）使用 .permitAll() 放行，最后用 .anyRequest().authenticated() 作为兜底。 关键点在于规则的顺序和精确度。

问题3：堆转储（heapdump）文件很大，下载和分析有什么技巧？

下载： 如果网络较慢，可以使用 wget 或 curl 的断点续传功能。 heapdump 端点生成的是二进制文件。
分析： 使用Eclipse Memory Analyzer Tool (MAT)是标准做法。但HPROF文件可能非常大（数GB）。一个实用技巧是，可以先使用命令行工具 strings 或 grep 快速搜索文件中是否包含明显的敏感关键词，以初步判断风险，再决定是否需要深入分析。
```
strings heapdump.hprof | grep -i "password\|secret\|key\|jdbc:mysql"
```

问题4：在Kubernetes中部署SpringBoot应用，如何安全地暴露Actuator？

最佳实践：
1. 使用独立的管理端口： 如上文所述，配置 management.server.port 为一个不同于主服务端口的值。
2. 通过K8s Service和NetworkPolicy隔离： 为管理端口创建一个独立的K8s Service，类型为 ClusterIP （不对外）。通过NetworkPolicy策略，严格限制只有特定的运维Pod（如Prometheus抓取指标）或来自运维命名空间的流量才能访问这个管理Service。
3. Ingress路由慎用： 绝对不要将管理端点的路径（如 /actuator ）通过Ingress暴露到公网。如果确实需要从外部访问（不推荐），应使用一个独立的、带有严格认证的Ingress，并配置双向TLS等强化措施。

问题5：历史遗留的SpringBoot 1.x应用如何防护？

核心差异： SpringBoot 1.x的Actuator端点路径没有 /actuator 前缀，且配置属性名不同（如 endpoints.env.enabled ）。
防护步骤：
1. 升级： 强烈建议制定计划升级到SpringBoot 2.x+，以获得更好的安全支持和社区维护。
2. 临时加固： 如果无法立即升级，必须在1.x的配置中显式禁用所有危险的端点，并为需要开启的端点配置Spring Security。同时，由于1.x默认通过HTTP暴露更多端点，风险更高，必须确保Spring Security覆盖所有路径。
```
# SpringBoot 1.x 配置示例 (application.properties)
endpoints.enabled=false # 先全部禁用
endpoints.health.enabled=true # 按需单独开启
endpoints.info.enabled=true
# 务必配置Spring Security
security.user.name=admin
security.user.password=strongPassword
security.user.role=ACTUATOR
```

安全是一个持续的过程，而非一劳永逸的状态。对于SpringBoot未授权访问漏洞，其防护的关键在于建立并执行严格的安全配置基线，将安全作为开发流程的固有环节，并通过持续的监控和测试来确保防护措施始终有效。每一次安全的代码提交、每一次严谨的配置审查、每一次主动的漏洞扫描，都是在为你的应用构筑更坚固的防线。