1. 项目概述

最近在复盘几个线上项目的安全审计报告，发现很多问题其实都是“老生常谈”，比如SQL注入、硬编码密钥、不安全的依赖版本。每次上线前都要手动翻一遍代码、查一遍配置，效率低还容易遗漏。于是，我花了点时间，结合自己踩过的坑和业界的最佳实践，整理了一份 Java项目安全加固Checklist（通用模板） 。这份清单的目的不是让你成为安全专家，而是给项目团队（尤其是开发、测试和运维同学）提供一个可执行、可落地的自查工具，在项目开发、测试、上线和运维的各个关键节点，快速过一遍，把那些最常见、最容易被利用的安全风险提前扼杀在摇篮里。

这份Checklist覆盖了从代码编写、依赖管理、配置安全到运行时防护、数据安全和运维监控的完整生命周期。它不追求面面俱到，但力求每一条都具体、可操作，能直接对应到你的代码库、配置文件或部署脚本中。无论你是维护一个庞大的微服务集群，还是开发一个简单的单体应用，都可以根据这份模板进行裁剪和适配，建立起适合自己团队的基础安全防线。接下来，我们就逐条拆解，看看每个环节到底该查什么、怎么查。

2. 安全加固Checklist设计思路与核心原则

2.1 为什么需要一份Checklist？

在快节奏的迭代开发中，安全很容易被当成“上线前的最后一道工序”，甚至是“出了问题再补的补丁”。这种事后补救的模式成本极高。一份好的Checklist，其核心价值在于 “左移” —— 将安全要求融入到需求分析、设计、编码、测试的每一个阶段。它就像一份飞行前检查单，帮助飞行员在起飞前系统性地排除风险，而不是在空中处理引擎故障。对于开发团队而言，Checklist提供了明确、统一的安全验收标准，减少了因个人经验差异导致的安全盲区，也让安全评审和代码审计变得有章可循。

2.2 本Checklist的设计原则

在整理这份清单时，我遵循了以下几个原则，这也是你在定制自己团队的清单时需要考量的：

1. 实用性优先 ：每一条检查项都必须能对应到具体的代码、配置或操作，避免空泛的“加强安全意识”之类的描述。例如，将“防止SQL注入”具体化为“是否全部使用预编译语句（PreparedStatement）或ORM框架的参数绑定功能？”。
2. 覆盖关键生命周期 ：安全不是某个阶段的事情。清单需要覆盖 编码阶段 （如输入验证）、 构建阶段 （如依赖扫描）、 部署阶段 （如配置检查）、 运行阶段 （如日志监控）和 运维阶段 （如密钥轮换）。
3. 风险分级 ：并非所有问题都同等紧急。清单应能区分 高危 （必须立即修复，如远程代码执行漏洞）、 中危 （限期修复，如敏感信息泄露）和 低危 （建议优化，如缺少安全头部）。在实际使用中，可以结合OWASP Top 10、CVE严重等级来定义。
4. 可自动化 ：尽可能将检查项转化为自动化脚本或工具集成到CI/CD流水线中。例如，使用SonarQube进行代码安全扫描，使用OWASP Dependency-Check检查依赖漏洞，使用Trivy扫描容器镜像。人工检查作为补充和兜底。
5. 持续演进 ：安全威胁在变化，技术栈在更新，Checklist也必须是一个“活文档”。团队应定期（如每季度）回顾清单，根据新的漏洞情报、业务变化和技术演进进行更新。

实操心得 ：一开始不要追求大而全。可以先从一个最核心的、最容易出问题的模块（比如用户登录注册）开始，制定针对性的Checklist，让团队跑通流程、看到效果（比如拦截了一次注入攻击），再逐步推广到全项目。强行推行一份上百项的复杂清单，很容易导致团队抵触和流于形式。

3. Java项目安全加固Checklist（通用模板）详解

以下清单按项目阶段和功能模块划分，每项包含 检查项 、 检查方法/标准 和 关联风险/原理说明 。

3.1 代码安全与开发规范

这部分主要关注编码过程中引入的安全漏洞，是安全问题的源头。

3.1.1 输入验证与输出编码

• 检查项1：所有用户输入是否都进行了有效的验证和过滤？
  • 检查方法 ：审查所有Controller、Service层中处理HTTP请求参数、Headers、Cookie、文件上传的方法。重点检查 @RequestParam ， @PathVariable ， @RequestBody 以及 HttpServletRequest.getParameter() 等获取输入的地方。
  • 标准 ：必须使用白名单机制进行验证。对于复杂数据，使用Bean Validation注解（如 @NotNull ， @Size ， @Pattern ， @Email ）。对于文件上传，必须验证文件类型（检查MIME Type和文件头，而非仅后缀名）、大小和内容。
  • 原理 ：缺乏输入验证是SQL注入、命令注入、路径遍历、XSS等漏洞的根源。白名单优于黑名单，因为攻击者的Payload总是千变万化。
• 检查项2：输出到HTML、JavaScript、CSS或URL的数据是否进行了正确的编码？
  • 检查方法 ：检查所有JSP、Thymeleaf、FreeMarker模板中直接使用 ${variable} 的地方，以及通过 response.getWriter().write() 输出数据的地方。
  • 标准 ：使用安全的输出编码函数。例如，在Thymeleaf中，默认的 th:text 已进行HTML转义。在JSP中，应使用JSTL的 <c:out value="${input}"> 或 fn:escapeXml() 。对于JavaScript上下文，需进行JavaScript转义。 绝对禁止 在HTML中拼接未编码的用户输入。
  • 原理 ：输出编码是防御跨站脚本攻击（XSS）的最后一道防线。确保数据在特定上下文中被当作纯文本处理，而不是可执行的代码。
• 检查项3：是否存在路径遍历漏洞？
  • 检查方法 ：搜索代码中所有使用 File ， Path ， getResourceAsStream 等文件操作相关的代码，特别是参数中包含 ../ 或类似路径跳转字符的。
  • 标准 ：对用户提供的文件路径进行规范化（ Path.normalize() ），并校验规范化后的路径是否在预期的安全目录内。更好的做法是使用文件ID映射，避免直接操作文件系统路径。
  • 原理 ：攻击者通过构造 ../../../etc/passwd 之类的路径，可能读取或写入系统敏感文件。

3.1.2 SQL与NoSQL注入防护

• 检查项4：数据库查询是否全部使用参数化查询（预编译语句）或安全的ORM框架？
  • 检查方法 ：全局搜索 Statement ， createStatement ， 以及字符串拼接的SQL语句（如 "SELECT * FROM users WHERE name = '" + name + "'" ）。
  • 标准 ：必须100%使用 PreparedStatement 或ORM框架（如MyBatis、JPA/Hibernate）的参数绑定功能。MyBatis中应使用 #{} 而非 ${} （后者为文本替换，存在风险）。对于复杂的动态SQL，可使用MyBatis的 <where> ， <if> 等标签配合 #{} 实现。
  • 原理 ：预编译语句将SQL语句结构与数据分离，数据库引擎会先编译SQL骨架，后续传入的参数无论内容如何，都会被当作数据而非指令执行，从根本上杜绝SQL注入。
• 检查项5：使用NoSQL（如MongoDB）时，查询是否避免了操作符注入？
  • 检查方法 ：检查MongoTemplate或直接使用MongoDB Driver的查询构造方式。
  • 标准 ：避免将用户输入直接拼接到查询JSON或BSON中。应使用驱动提供的类型安全查询构建器（如Spring Data MongoDB的 Query 和 Criteria 类）。
  • 原理 ：类似于SQL注入，攻击者可能通过注入 $where ， $ne 等MongoDB操作符来操纵查询逻辑。

3.1.3 命令执行与反序列化

• 检查项6：是否避免了直接执行操作系统命令？
  • 检查方法 ：搜索 Runtime.exec() ， ProcessBuilder ， @ 符号（在Windows命令中）。
  • 标准 ： 首选方案是寻找纯Java的替代库 。如果必须执行命令，应使用白名单严格限制可执行的命令和参数，并对参数进行严格的过滤（如只允许字母、数字、特定符号）。避免使用Shell（如 bash -c ， cmd /c ），因为它们会解析元字符。
  • 原理 ：命令注入危害极大，可导致服务器被完全控制。任何来自外部的输入（包括文件名、配置项）都可能成为命令的一部分。
• 检查项7：反序列化操作是否安全？
  • 检查方法 ：检查使用 ObjectInputStream ， XMLDecoder ， XStream ， Jackson 的 readValue （针对多态类型），以及任何自定义的反序列化逻辑。
  • 标准 ：
    1. 白名单校验 ：使用 ObjectInputStream 时，应重写 resolveClass 方法，只允许反序列化预期的类。
    2. JEP 290 ：对于使用JDK 8u121, 7u131, 6u141及以上版本的应用，可以配置JVM参数 -Djdk.serializationFilter 来设置反序列化过滤器，这是最有效的全局防护手段。
    3. 避免危险库 ：避免使用已知不安全的反序列化库（如老版本的XStream）。
    4. 数据可信 ：只反序列化来自可信来源的数据。
  • 原理 ：Java反序列化漏洞利用链可以导致远程代码执行（RCE），是极高危漏洞。攻击者通过精心构造的序列化数据，触发目标类库中的危险方法（如 Runtime.exec ）。

3.2 依赖与组件安全

现代Java项目严重依赖第三方库，一个脆弱的依赖可能就是整个系统的“阿喀琉斯之踵”。

3.2.1 依赖漏洞管理

• 检查项8：是否定期（至少每次构建时）扫描项目依赖中的已知漏洞？
  • 检查方法 ：检查CI/CD流水线或本地构建脚本中是否集成了依赖安全检查工具。
  • 标准 ：必须集成自动化扫描工具。推荐工具：
    • OWASP Dependency-Check ：可与Maven、Gradle集成，生成包含CVE编号的漏洞报告。
    • GitHub Dependabot / GitLab Dependency Scanning ：如果代码托管在这些平台，可以启用其内置的依赖扫描和自动升级PR功能。
    • Snyk ：提供更详细的漏洞描述和修复建议。
  • 修复策略 ：对于扫描出的高危、中危漏洞，应制定明确的修复SLA（如高危7天内，中危30天内）。优先通过升级依赖版本修复。如果无法升级，需评估漏洞是否在特定条件下才能触发，并实施其他缓解措施（如网络隔离、WAF规则）。
• 检查项9：是否使用了来源不可靠或已停止维护的组件？
  • 检查方法 ：审查 pom.xml 或 build.gradle 中所有依赖的GroupId和ArtifactId。关注其GitHub仓库的活跃度（最后提交时间、Issue处理情况）、维护团队等信息。
  • 标准 ：优先选择Apache、Eclipse、知名公司（如Google、Netflix）维护的，或社区活跃度高的开源组件。对于内部私有依赖，应有明确的维护团队和版本策略。

3.2.2 依赖固化与供应链安全

• 检查项10：构建是否具有可重现性？依赖版本是否被固化？
  • 检查方法 ：检查是否使用了Maven的 dependencyManagement 或Gradle的 dependency locking 功能。
  • 标准 ：使用 maven-dependency-plugin 的 purge-local-repository 目标或Gradle的 --write-locks 命令来生成依赖锁文件（如 gradle.lockfile ），并提交到版本库。这确保了所有环境（开发、测试、生产）使用完全相同的依赖树，避免因间接依赖的隐式升级引入未知风险。
  • 原理 ：供应链攻击可能发生在任何环节。固化依赖版本是保证构建一致性和安全性的基础。

3.3 配置与运行时安全

错误的配置是导致安全事件的主要原因之一，所谓“默认即不安全”。

3.3.1 应用服务器与框架配置

• 检查项11：是否禁用了不必要的HTTP方法（如PUT， DELETE， TRACE， CONNECT）？
  • 检查方法 ：检查Tomcat、Spring Security等相关配置。
  • 标准 ：在Web服务器（如Nginx）或应用框架层（如Spring Security的 HttpSecurity 配置）中，显式地只允许业务需要的HTTP方法（通常是GET， POST）。对于RESTful API，可根据实际情况开放PUT， DELETE，但必须配合严格的权限校验。
  • 原理 ：TRACE方法可能用于跨站追踪攻击，不必要的PUT， DELETE方法可能被用于篡改或删除资源。
• 检查项12：是否设置了安全相关的HTTP响应头？
  • 检查方法 ：使用浏览器开发者工具或 curl -I 命令检查应用响应头。
  • 标准 ：至少应配置以下头部：

    响应头	作用与推荐值
    X-Content-Type-Options: nosniff	阻止浏览器MIME类型嗅探，降低驱动式下载攻击风险。
    X-Frame-Options: DENY 或 SAMEORIGIN	防止页面被嵌入iframe，用于点击劫持防护。
    Strict-Transport-Security: max-age=31536000; includeSubDomains	强制使用HTTPS（HSTS）。
    Content-Security-Policy	内容安全策略，有效防御XSS。初始可配置为较严格的策略，如 default-src 'self' 。
    Referrer-Policy: strict-origin-when-cross-origin	控制Referer头的发送，减少信息泄露。

  • 配置方式 ：可通过Spring Security的 HeadersConfigurer ， Servlet Filter或Web服务器（Nginx）配置。
• 检查项13：是否正确配置了CORS（跨域资源共享）？
  • 检查方法 ：检查Spring的 @CrossOrigin 注解或 WebMvcConfigurer 配置。
  • 标准 ：遵循“最小权限原则”。避免使用 allowedOrigins: "*" 。应明确指定允许跨域的源（域名、协议、端口）。对于需要携带凭证（Cookie、Authorization头）的请求，必须设置 allowCredentials: true ，并且 allowedOrigins 不能为通配符 * 。
  • 原理 ：宽松的CORS配置可能导致敏感数据被恶意网站读取。

3.3.2 会话管理与身份认证

• 检查项14：会话Cookie是否设置了 HttpOnly 和 Secure 属性？
  • 检查方法 ：检查浏览器中会话Cookie的属性。
  • 标准 ： HttpOnly: true （防止JavaScript访问，缓解XSS窃取会话）、 Secure: true （仅通过HTTPS传输）。在Spring Boot中，可通过 server.servlet.session.cookie.http-only=true 和 server.servlet.session.cookie.secure=true 配置（生产环境HTTPS下）。
• 检查项15：会话超时时间是否合理？是否实现了会话固定攻击防护？
  • 检查方法 ：检查会话超时配置（如 server.servlet.session.timeout ）和登录逻辑。
  • 标准 ：会话超时时间不宜过长（如30分钟）。用户登录成功后， 必须 使旧的会话失效并创建一个新的会话ID（ session.invalidate() + request.getSession(true) ）。这是防御会话固定攻击的标准做法。
• 检查项16：密码是否以明文形式存储或传输？
  • 检查方法 ：检查数据库中的密码字段、日志文件、以及登录请求的流量（确保是HTTPS）。
  • 标准 ：
    1. 传输 ：必须使用HTTPS。
    2. 存储 ：必须使用强哈希算法（如Argon2， bcrypt， scrypt， PBKDF2）加盐存储。 绝对禁止 使用MD5、SHA-1等快速哈希算法。Spring Security的 BCryptPasswordEncoder 是很好的选择。
    3. 日志 ：确保密码等敏感信息不会因异常堆栈等信息被记录到日志中。

3.3.3 敏感信息管理

• 检查项17：代码和配置文件中是否存在硬编码的密码、API密钥、加密密钥？
  • 检查方法 ：使用代码扫描工具（如GitHub Secret Scanning， GitLeaks， TruffleHog）或正则表达式在代码库中搜索常见的关键词（如 password ， secret ， key ， token ）。
  • 标准 ：所有敏感信息必须从代码中剥离，通过环境变量、配置中心（如Spring Cloud Config， Apollo）或专业的密钥管理系统（如HashiCorp Vault， AWS KMS， 阿里云KMS）在运行时动态注入。
• 检查项18：配置文件（如 application.properties ， application.yml ）是否被提交到公开的版本库？
  • 检查方法 ：检查 .gitignore 文件是否排除了包含生产环境配置的文件。
  • 标准 ：提交一个模板配置文件（如 application-template.properties ），而将包含真实敏感信息的配置文件（如 application-prod.properties ）纳入 .gitignore 。生产配置通过CI/CD流程或配置中心管理。

3.4 数据安全与隐私保护

• 检查项19：日志中是否记录了敏感信息（如身份证号、手机号、银行卡号）？
  • 检查方法 ：审查日志输出语句，特别是异常捕获处的 e.printStackTrace() 或 logger.error(“xxx”, e) 。
  • 标准 ：在记录日志前，必须对敏感信息进行脱敏。可以编写一个工具类或使用日志框架的转换器（如Logback的 MessageConverter ），将匹配特定模式（如身份证、手机号）的字符串替换为 *** 。
• 检查项20：返回给前端的数据是否包含了不必要的敏感字段？
  • 检查方法 ：检查API返回的DTO对象。特别是用户查询、列表查询等接口。
  • 标准 ：遵循“最小必要原则”。为前端不同的场景定义不同的VO（View Object），使用 @JsonIgnore 注解或MapStruct等工具在序列化时排除敏感字段（如 password ， salt ， 内部状态位）。
• 检查项21：是否对用户个人敏感信息（PII）的存储和访问有明确的合规性设计？
  • 检查方法 ：检查数据库表设计、数据访问层（DAO）的权限控制。
  • 标准 ：根据业务合规要求（如GDPR， 个人信息保护法），可能需要对敏感字段进行加密存储（应用层加密或数据库透明加密），并实现严格的访问审计日志，记录“谁在什么时候访问了谁的什么数据”。

3.5 运维与基础设施安全

• 检查项22：生产环境的调试接口（如Actuator， Swagger， Druid监控）是否对外暴露？
  • 检查方法 ：检查生产环境部署的组件和端口。
  • 标准 ：Spring Boot Actuator端点（尤其是 /env ， /heapdump ， /trace ）、Swagger UI、数据库连接池监控（如Druid）等管理接口， 绝不能 直接暴露在公网。应通过内网访问、设置强密码认证、或通过网关/防火墙进行IP白名单限制。
• 检查项23：容器镜像是否基于最小化基础镜像构建？
  • 检查方法 ：检查Dockerfile中的 FROM 指令。
  • 标准 ：使用 openjdk:xx-jre-slim 或 eclipse-temurin:xx-jre 等仅包含JRE的轻量级镜像，而不是完整的JDK镜像。这能显著减少攻击面。
• 检查项24：容器是否以非root用户运行？
  • 检查方法 ：检查Dockerfile中是否包含 USER 指令。
  • 标准 ：在Dockerfile中创建并切换到一个非root用户（如 RUN addgroup -S appgroup && adduser -S appuser -G appgroup ， USER appuser ）。这遵循了最小权限原则，即使容器被突破，攻击者获得的权限也有限。
• 检查项25：是否有应用和系统的监控告警？
  • 检查方法 ：检查是否集成了监控系统（如Prometheus + Grafana）和日志聚合系统（如ELK）。
  • 标准 ：监控关键指标（如QPS， 错误率， 响应延迟， JVM内存/GC）。设置针对安全事件的告警规则，例如：同一IP短时间内登录失败次数过多、异常的业务操作日志（如大量查询、敏感数据导出）、未知的进程启动等。

4. 如何落地与执行这份Checklist

一份再好的清单，如果束之高阁也毫无价值。关键在于将其融入开发流程。

4.1 集成到开发流程中

1. 编码阶段（IDE集成） ：将部分检查项转化为IDE的实时检查规则。例如，在IntelliJ IDEA中配置SonarLint插件，实时提示硬编码密码、不安全的反序列化等问题。
2. 提交前（Git Hooks） ：利用 pre-commit 钩子，运行简单的代码风格和安全模式扫描（如使用 spotbugs ， pmd ），阻止有明显问题的代码提交。
3. 持续集成（CI Pipeline） ：这是最重要的自动化关卡。在Jenkins， GitLab CI， GitHub Actions等CI流水线中，顺序执行：
   • 代码静态分析（SAST）：SonarQube， Checkmarx。
   • 依赖漏洞扫描（SCA）：OWASP Dependency-Check， Snyk。
   • 容器镜像扫描：Trivy， Clair。
   • 安全单元测试：针对自研的安全组件（如加密工具类）编写测试用例。
   • 关键 ：将扫描结果与流水线门禁结合。可以设置策略，如“出现1个高危漏洞则流水线失败”，强制修复。
4. 代码审查（Pull Request） ：在PR描述模板中，加入一个安全检查章节，要求开发者自检并勾选相关项。审查者也将安全检查作为必审内容。
5. 上线前与定期巡检 ：在上线checklist中纳入关键安全项。同时，运维团队应定期（如每月）使用漏洞扫描器（如Nessus， OpenVAS）对生产环境进行网络层和应用层扫描，与Checklist形成互补。

4.2 制定安全红线与处理流程

团队需要共识哪些问题是绝对不能上线的“安全红线”。通常包括：

• 高危的第三方依赖漏洞（CVSS评分 >= 7.0）。
• 明确的远程代码执行（RCE）、SQL注入、严重的信息泄露漏洞。
• 生产环境敏感信息（数据库密码、私钥）硬编码或明文存储。 对于触犯红线的代码，CI流水线应自动失败，并且只有修复后才能合并。团队应建立清晰的安全事件应急响应流程，明确漏洞上报、评估、修复、验证的步骤和责任人。

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

在实际推行Checklist的过程中，你肯定会遇到各种疑问和阻力。这里记录几个典型问题和我的处理经验。

• 问题1：依赖漏洞扫描报出一个高危漏洞，但升级版本会导致大量不兼容的API变更，短期内无法修复，怎么办？
  • 排查与决策 ：首先，深入分析该漏洞的利用条件（CVSS向量）。有些漏洞需要特定的、你的应用不满足的条件才能触发（例如，需要特定的JDK版本、特定的序列化场景）。如果确认在当前的业务上下文和技术栈中该漏洞无法被利用，可以将其标记为“已评估，风险可接受”，但 必须记录在案 ，并制定远期升级计划。同时，寻找其他缓解措施，例如：通过网络ACL限制对受影响服务的访问、在WAF上添加针对该漏洞的防护规则。 切忌无视或隐瞒 。
• 问题2：为了快速上线，业务方要求临时放宽某个安全要求（比如先允许CORS为 * ），该如何处理？
  • 处理原则 ：安全需要平衡业务需求，但不能无原则妥协。我的做法是：
    1. 评估风险 ：明确告知放宽此要求的具体风险（如可能导致用户数据被恶意网站窃取）。
    2. 提供替代方案 ：给出一个更安全的临时方案（例如，只允许前端的特定域名，并承诺在X天内改为更精确的配置）。
    3. 书面记录 ：如果业务方在知晓风险后仍坚持，需要其书面（如邮件、IM记录）确认并承诺修复时限。将此记录归档，作为后续审计和追责的依据。这既是对业务负责，也是对安全团队自身的保护。
• 问题3：Checklist条目太多，开发同学抱怨影响效率。
  • 优化策略 ：这是推行任何流程都会遇到的挑战。解决方法：
    • 分层分级 ：将Checklist分为“基础级”（所有项目必须）和“增强级”（对安全要求高的项目）。新项目先从基础级开始。
    • 工具赋能 ：将尽可能多的检查自动化。如果一项检查需要人工逐行看代码，那它很可能被忽略。把它变成IDE的警告、CI的自动失败，开发者的抵触情绪会小很多。
    • 培训与案例 ：定期分享因忽略某条Checklist而导致的实际安全事件（内部或外部）。用事实让团队理解每一条要求背后的血泪教训，变“要我安全”为“我要安全”。
• 问题4：生产环境突然出现大量错误，怀疑是安全更新导致，如何快速定位？
  • 排查思路 ：首先查看监控和日志，定位错误发生的具体服务、接口和时间点。核对最近的变更记录，特别是：
    1. 是否有依赖库升级？
    2. 是否有安全配置（如CSP头部、密码策略）被修改？
    3. 是否部署了新的WAF或防火墙规则？
  • 回滚与测试 ：如果怀疑是安全变更引起，立即执行回滚操作。在测试环境复现该变更，并运行完整的回归测试套件，特别是涉及安全功能的测试用例。 教训 ：任何安全变更，尤其是涉及核心组件和网络策略的，必须在测试环境充分验证，并准备好一键回滚方案。

安全是一个持续的过程，而非一劳永逸的状态。这份Checklist是一个起点，而不是终点。它应该随着你的项目、你的团队以及外部威胁环境的变化而不断演进。最关键的，是让团队中的每一个人都建立起基本的安全意识，并在日常工作中养成“安全地思考”的习惯。当你发现开发同学在写代码时会下意识地想到“这里要不要做参数校验”，测试同学会主动去验证一个异常输入，运维同学会关注一个异常的访问日志时，这份Checklist的价值才算真正体现。