按框架
Spring Boot 安全防护 — 依赖 CVE、Actuator 暴露与授权的守护方法
Spring Boot 的事故类型：依赖包的已知 CVE（如 Log4Shell）、Actuator 等管理端点暴露、Spring Security 授权设置缺失、不安全的反序列化。用机器监控依赖 CVE 并快速打补丁、收紧管理面、显式授权。防御视角，不含攻击步骤。
面向：正在运营 Java / Spring Boot 应用的人。这里不讲攻击步骤——只讲事故的类型，以及如何堵住它们。 想看全局，请参阅 按框架的安全防护入口。
事故的类型（连稳固地基也会被打中的地方）
Spring Boot 和 Spring Security 已经成熟，但下面这四点是要在运营中管理的领域。
① 依赖包的已知 CVE
Log4Shell 等——被广泛继承的地基缺陷一次性波及。按实际运行版本判定，快速打补丁。
② Actuator / 管理面暴露
暴露的诊断/管理端点会泄露信息或被用来操作。收紧范围。
③ 授权缺失
Spring Security 配置疏漏让权限检查薄弱。有认证，但授权不足。
④ 不安全的反序列化
还原不可信数据可能导致 RCE。要核实输入的来源。
如何堵住（四种管理）
用机器监控依赖 CVE 并快速打补丁
收紧 Actuator 与管理面
用 Spring Security 显式授权
不反序列化不可信数据
常见（危险）
- 放任依赖的已知 CVE 不打补丁（含地基库）
- Actuator 以完全暴露的状态上生产
- 授权全交给默认值，留下配置疏漏
- 直接反序列化不可信数据
正确
- 依赖 CVE 机器监控＋快速打补丁（按实际运行版本）
- Actuator/管理面最小暴露＋要求认证
- 在 Spring Security 中显式授权
- 反序列化核实来源、限定格式
本站的视角：地基越稳，胜负越取决于依赖和公开面
Spring 是稳固的地基，但正因为它被广泛使用，一个依赖库的缺陷就会一次性波及所有人。Log4Shell 就是这一点的象征，而核心防御与其说是某个具体设置，不如说是用机器监控依赖、按实际运行版本判定、快速打补丁的运营习惯。与此同时，把便捷的管理端点（Actuator）挪出公开面，别把授权交给默认值。本站是另一套技术栈，但原则完全一致——依赖的新鲜度、公开面的最小化、显式授权无论用什么框架都有效（→ 监控依赖 CVE）。
接下来读
- 入口：按框架的安全防护 · Next.js 安全
- 事故：Log4Shell 剖析（一个被广泛继承的地基缺陷）
- 实操：漏洞应对实务 · 监控依赖 CVE · 术语：什么是 RCE
FAQ
QSpring（Spring Boot）安全吗？
Spring Boot 和 Spring Security 是成熟稳固的地基，配置得当时相当强。但事故并非来自核心，而是来自它被广泛使用这一点：依赖包的已知 CVE（如 Log4Shell，一个地基日志库的缺陷一次性波及无数应用）、Actuator 等管理端点暴露、授权配置缺失。正因久经沙场，它也是巨大的靶子，所以真正要紧的是依赖的新鲜度和公开面的管理。
Q使用 Actuator 时该注意什么？
Actuator 提供了查看运行时信息和诊断的便捷管理端点，但一旦暴露就可能泄露内部信息，视配置还可能成为被操作的跳板。在生产环境要把它的暴露收紧到最小、必须要求认证与授权，并放在外部无法触及的网络边界之后。不要以『方便就全部开启』的状态上线。
Q如何为 Log4Shell 这类依赖缺陷做准备？
Log4Shell 是一个被广泛继承的日志库缺陷一次性波及大量应用的经典案例。核心准备是用机器监控依赖包的已知 CVE 并快速打补丁，且要按实际运行版本判定——不是看 pom.xml 里的声明，而是看真正构建并运行的版本。用最小权限和网络分段来缩小爆炸半径也很有帮助。