Spring Boot应用安全配置实战：7个关键防护点与最佳实践-CSDN博客

1. 项目概述：为什么Spring Boot应用需要一份专属的安全指南？

最近在整理团队内部的技术资产，发现一个挺普遍的现象：很多基于Spring Boot开发的应用，在安全配置上要么是“祖传代码”直接复制粘贴，要么就是东拼西凑，知其然不知其所以然。尤其是在使用像Claude Code Template这类代码生成工具快速搭建项目骨架后，开发者往往把重心都放在了业务逻辑的实现上，而忽略了那些默认配置背后可能存在的安全风险。这让我想起之前处理过的一次线上安全预警，一个内部管理系统的用户会话竟然可以被轻易劫持，根源就在于一个被忽视的Cookie配置。

所以，我决定结合自己踩过的坑和最佳实践，梳理一份针对Spring Boot应用，特别是基于Claude Code Template这类模板生成项目的安全配置指南。这份指南的目标不是面面俱到地讲Spring Security的所有功能，而是聚焦于 7个最核心、最容易被忽略，但一旦出问题后果往往很严重的关键安全配置 。无论你是刚接手一个老项目，还是正准备启动一个新服务，花上十几分钟对照检查一遍，很可能就能避免未来一个通宵的紧急故障排查。

简单来说，这份指南要解决的核心问题是：在享受Spring Boot和代码模板带来的开发便利的同时，如何通过一系列明确、可落地的配置，为你的应用构筑起一道坚实可靠的基础安全防线，让“安全”不再是一个模糊的概念，而是一组具体的、可检查的开关和参数。

2. 安全配置的整体设计思路与原则

在开始逐个拆解那7个关键配置之前，我们必须先统一思想：安全配置不是一堆孤立参数的堆砌，而是一个有层次、有侧重的防御体系设计。我的思路主要遵循以下三个原则：

2.1 默认安全原则：从“不安全”到“安全”的思维转变

Spring Boot以其“约定优于配置”的理念闻名，但在安全上，很多默认约定是为了开发便利而设计的，并非生产环境的最佳实践。例如，默认的 server.error.include-stacktrace 配置会在错误响应中包含堆栈信息，这在开发时很有用，但在生产环境会泄露内部代码结构。我们的配置思路，首要任务就是 扭转这些默认的不安全状态 ，将安全作为默认选项。这意味着我们需要主动去识别和关闭那些“为了方便而开放”的功能，比如禁用不必要的HTTP方法、关闭默认的管理端点等。

2.2 纵深防御原则：不依赖单一安全措施

不要指望一个HTTPS或者一个复杂的密码策略就能解决所有问题。纵深防御意味着在不同的层次（网络层、传输层、应用层、数据层）和同一层次的不同点都部署安全措施。例如，在应用层，我们既要防止SQL注入（通过ORM框架的参数化查询），也要防止XSS攻击（通过响应头配置），还要控制会话安全。这样，即使一层防御被突破，其他层的防御仍然能提供保护。本文的7个配置，正是覆盖了应用层中几个关键的防御点。

2.3 最小权限原则：只授予必要的访问能力

这是安全领域的黄金法则。应用到Spring Boot配置上，它体现在多个方面：数据库连接账户只拥有其业务所需的最低权限；应用运行的操作系统用户不应是root；更重要的是，对于应用自身的功能模块和API端点，访问权限必须精确控制。Spring Security的权限表达式和 @PreAuthorize 注解就是实现这一原则的利器。我们的配置会确保未认证的用户只能访问明确公开的资源，任何其他请求都必须经过严格的身份和权限校验。

基于以上原则，我筛选出的7个关键配置，正是从“纠正默认不安全”、“构建多层防御”、“实施精确管控”这三个维度出发，它们共同构成了Spring Boot应用安全基线的“四梁八柱”。

3. 关键安全配置一：强制HTTPS与传输安全加固

第一个要敲黑板的配置，就是确保所有通信都在加密通道中进行。在内部网络环境可能变得复杂，任何明文传输的凭证、会话ID或敏感数据都是潜在的风险源。

3.1 在Spring Boot中强制启用HTTPS

如果你已经为服务配置了SSL证书（无论是自签名还是由受信CA签发），在 application.yml 或 application.properties 中强制重定向HTTP到HTTPS是最佳实践。

# application.yml 配置示例
server:
  port: 8443 # HTTPS端口
  ssl:
    key-store: classpath:keystore.p12
    key-store-password: your-strong-password
    key-store-type: PKCS12
    key-alias: your-alias
  # 如果需要同时监听HTTP端口并重定向，可以额外配置

然而，仅配置SSL还不够。更可靠的做法是在应用入口处（如使用Nginx）终止SSL，并在应用内通过配置强制所有请求必须使用安全通道。Spring Security可以轻松实现这一点：

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            // 其他配置...
            .requiresChannel()
                .anyRequest().requiresSecure() // 强制所有请求使用HTTPS
            .and()
            // ... 其他安全规则
    }
}

注意：在使用反向代理（如Nginx）时，代理服务器需要正确设置 X-Forwarded-Proto 头，Spring Boot应用才能准确判断原始请求是否安全。你需要确保代理配置中包含类似 proxy_set_header X-Forwarded-Proto $scheme; 的指令，并在Spring Boot中配置 server.use-forward-headers=true 或 server.forward-headers-strategy=NATIVE 。

3.2 配置安全相关的HTTP响应头

这是防止常见Web攻击（如点击劫持、MIME类型嗅探、XSS等）的低成本高收益手段。Spring Security默认提供了一些，但我们可以更严格。

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .headers()
            .contentSecurityPolicy("default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';") // 内容安全策略，有效对抗XSS
            .and()
            .frameOptions().deny() // 防止点击劫持，禁止页面被嵌入Frame
            .and()
            .httpStrictTransportSecurity()
                .includeSubDomains(true)
                .maxAgeInSeconds(31536000) // 强制浏览器使用HTTPS长达一年
            .and()
            .contentTypeOptions().disable() // 实际上，我们应该启用它以防止MIME嗅探
        .and()
        // ... 其他配置
}

这里特别说明一下 Content-Security-Policy (CSP) ：这是对抗XSS的利器。上面的策略是一个相对严格的起点，它要求所有资源（如脚本、样式）默认只能从当前域名加载。如果你的页面使用了CDN上的jQuery或Bootstrap，就需要在 script-src 和 style-src 中明确添加这些CDN的域名。配置CSP可能需要一个调试过程，浏览器的开发者工具控制台会明确报告哪些资源被阻止了。

3.3 实操心得：关于HSTS的坑

Strict-Transport-Security (HSTS) 头非常有用，但它是一把双刃剑。一旦浏览器接收了这个头并在有效期内，它就会强制对该域名使用HTTPS。如果你在开发或测试环境错误地配置了HSTS，之后又想用HTTP访问，就会非常麻烦。 我的建议是：在本地开发环境和测试环境不要启用HSTS，或者将其 maxAgeInSeconds 设置为一个很小的值（如300秒）。 生产环境的配置也最好在确保HTTPS完全稳定后再开启。

4. 关键安全配置二：会话管理与会话固定攻击防护

HTTP会话是Web应用维持用户状态的核心机制，也是最常被攻击的目标之一。不安全的会话配置可能导致会话劫持、会话固定等攻击。

4.1 安全配置会话Cookie

Cookie是会话ID最常见的载体，其属性直接关系到安全性。

# application.yml
server:
  servlet:
    session:
      cookie:
        http-only: true    # 防止JavaScript通过document.cookie访问，对抗XSS窃取会话
        secure: true       # 仅通过HTTPS传输Cookie，防止网络嗅探
        same-site: strict  # 严格禁止跨站请求携带Cookie，有效防御CSRF攻击
      # 也可以配置会话超时时间
      timeout: 30m         # 30分钟无活动则会话失效

http-only : 必须为 true 。这能确保即使网站存在XSS漏洞，攻击者注入的脚本也无法直接窃取到会话Cookie。
secure : 在启用HTTPS后必须为 true 。
same-site : 设置为 Strict 或 Lax 。 Strict 安全性最高，但可能导致从第三方网站链接跳转回来时用户会话丢失（需要重新登录）。对于大多数应用， Lax 是一个平衡的选择，它允许顶级导航（如点击链接）携带Cookie，但阻止跨站的POST请求（即CSRF攻击的主要载体）。 Spring Boot 2.1及以上版本默认就是 Lax ，但最好显式声明。

4.2 防御会话固定攻击

会话固定攻击的原理是攻击者先获取一个有效的会话ID，然后诱骗受害者使用这个会话ID登录系统，从而获得受害者的权限。Spring Security默认已经提供了防御机制，但我们需要确保它被启用并正确配置。

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .sessionManagement()
            .sessionFixation().migrateSession() // 或者 .newSession()
        .and()
        // ... 其他配置
}

migrateSession() : （默认策略）登录成功后，创建一个新的会话，并将旧会话的属性复制到新会话中，然后使旧会话失效。这是最常用的策略。
newSession() : 登录成功后，创建一个全新的、干净的会话，不复制任何属性。适用于对安全要求极高的场景。
none() : 危险！ 不采取任何措施，应用容易受到会话固定攻击。
changeSessionId() : Servlet 3.1+容器提供的机制，效果类似 migrateSession 。

4.3 实操心得：分布式会话的注意事项

如果你的应用部署在多台服务器上（比如通过Kubernetes或简单的负载均衡），那么默认的基于内存的会话存储就不可用了。你需要将会话外部化，例如存储到Redis中。

<!-- pom.xml 添加依赖 -->
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>io.lettuce</groupId>
    <artifactId>lettuce-core</artifactId> <!-- 或使用Jedis -->
</dependency>

# application.yml
spring:
  session:
    store-type: redis
    timeout: 30m
  redis:
    host: localhost
    port: 6379

使用外部会话存储后，之前提到的 http-only 、 secure 、 same-site 等Cookie属性配置依然有效，它们控制的是浏览器端的Cookie行为。而会话内容本身则安全地存储在Redis里。 务必确保Redis服务本身的安全，如设置密码、限制访问IP等。

5. 关键安全配置三：密码编码器与存储策略

用户密码是最后一道防线，绝对不能以明文存储。Spring Security提供了强大的密码编码器支持。

5.1 弃用弱编码器，使用BCryptPasswordEncoder

NoOpPasswordEncoder （明文）、 StandardPasswordEncoder （SHA-256，但未加盐）都已过时且不安全。当前社区公认的最佳选择是 BCryptPasswordEncoder 。

@Configuration
public class PasswordEncoderConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        // 使用BCrypt，强度因子默认为10。强度越高越安全，但计算耗时也越长。
        // 对于常规Web应用，10是一个很好的平衡点。
        return new BCryptPasswordEncoder(10);
    }
}

BCrypt的优点在于它内置了盐（salt），并且盐会作为编码后字符串的一部分存储起来，这样即使两个用户密码相同，编码后的结果也完全不同，可以有效抵御彩虹表攻击。同时，BCrypt是一种自适应哈希函数，可以通过调整强度因子来应对计算能力的提升。

5.2 在Spring Security配置中注入编码器

定义好编码器后，需要在Spring Security的配置中显式指定它，用于密码校验和用户详情服务。

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private UserDetailsService userDetailsService;

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userDetailsService)
            .passwordEncoder(passwordEncoder); // 关键：在这里指定密码编码器
    }

    // ... 其他配置
}

在你的 UserDetailsService 实现中，从数据库加载的用户密码应该是已经用 BCryptPasswordEncoder 编码过的字符串。当用户登录时，Spring Security会自动使用配置的编码器对用户输入的密码进行编码，然后与数据库存储的编码后密码进行比对。

5.3 实操心得：密码升级策略

对于遗留系统，数据库中可能存储着用MD5或SHA-1等弱算法编码的密码。直接切换到BCrypt会导致所有老用户无法登录。一个平滑的迁移策略是使用 DelegatingPasswordEncoder 。

@Bean
public PasswordEncoder passwordEncoder() {
    String idForEncode = "bcrypt";
    Map<String, PasswordEncoder> encoders = new HashMap<>();
    encoders.put(idForEncode, new BCryptPasswordEncoder());
    encoders.put("sha256", new StandardPasswordEncoder()); // 仅用于兼容旧密码

    PasswordEncoder passwordEncoder = new DelegatingPasswordEncoder(idForEncode, encoders);
    // 设置默认的编码器，用于处理没有前缀的旧密码（不推荐，仅作示例）
    // ((DelegatingPasswordEncoder) passwordEncoder).setDefaultPasswordEncoderForMatches(encoders.get("sha256"));
    return passwordEncoder;
}

DelegatingPasswordEncoder 存储的密码字符串会带有一个前缀，例如 {bcrypt}... 或 {sha256}... 。在验证时，它会根据前缀选择对应的编码器进行校验。当用户用旧密码成功登录后，你可以在后台用新的BCrypt算法重新编码其密码并更新数据库，从而逐步完成密码存储的升级。

6. 关键安全配置四：细粒度的请求授权与CSRF防护

授权是安全的核心，它决定了“谁能在什么条件下访问什么资源”。同时，对于有状态Web应用（使用会话），CSRF防护必不可少。

6.1 构建清晰的URL访问规则

不要使用模糊的 anyRequest().authenticated() 就了事。应该为所有API和页面路径定义明确的访问规则。规则应按从具体到一般的顺序排列。

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
            // 1. 公开资源（静态资源、登录页、注册页等）放行
            .antMatchers("/css/**", "/js/**", "/images/**", "/webjars/**").permitAll()
            .antMatchers("/login", "/register", "/api/public/**").permitAll()
            // 2. 拥有特定角色的用户才能访问的管理接口
            .antMatchers("/admin/**").hasRole("ADMIN")
            .antMatchers("/api/manager/**").hasAnyRole("MANAGER", "ADMIN")
            // 3. 需要特定权限才能访问的API（更细粒度）
            .antMatchers(HttpMethod.DELETE, "/api/projects/**").hasAuthority("PROJECT_DELETE")
            // 4. 个人资料相关，要求当前认证用户ID与路径ID匹配
            .antMatchers("/api/users/{userId}/**").access("@userSecurity.checkUserId(authentication, #userId)")
            // 5. 其他所有请求都需要认证
            .anyRequest().authenticated()
        .and()
        // ... 表单登录、异常处理等配置
}

6.2 方法级安全控制

URL层面的控制有时不够精细，特别是对于服务层的方法。可以使用 @PreAuthorize , @PostAuthorize , @Secured 等注解。

@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration {
}

在Service方法上使用：

@Service
public class ProjectService {

    @PreAuthorize("hasRole('USER') and @projectSecurity.isOwner(#projectId, authentication)")
    public void deleteProject(Long projectId) {
        // ... 删除项目逻辑
    }

    @PostAuthorize("returnObject.owner.username == authentication.name or hasRole('ADMIN')")
    public Project getProject(Long id) {
        // ... 获取项目逻辑
    }
}

6.3 理解并启用CSRF防护

CSRF（跨站请求伪造）攻击诱使已登录的用户在不知情的情况下提交恶意请求。Spring Security默认对非 GET 、 HEAD 、 TRACE 、 OPTIONS 的请求（即状态变更请求）启用CSRF防护。

对于传统同步Web应用（如Thymeleaf, JSP） ：Spring Security会自动在表单中添加一个名为 _csrf 的隐藏域，包含令牌。你无需额外操作。
对于RESTful API或无状态应用 ：如果前端是独立的SPA（如Vue、React），并且使用Token（如JWT）进行认证，通常 需要禁用CSRF防护 ，因为CSRF防护依赖于会话，而无状态API不依赖会话。
```
@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .csrf().disable() // 对于无状态JWT API，通常禁用CSRF
        // ... 其他配置
}
```
禁用CSRF的前提是你已经采用了其他足够安全的认证方式（如JWT），并且妥善处理了CORS（跨域资源共享）。

6.4 实操心得：CORS配置的陷阱

如果你的前端应用部署在不同的域名或端口下，就需要配置CORS。不安全的CORS配置会带来严重风险。

@Configuration
public class CorsConfig {

    @Bean
    public CorsFilter corsFilter() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        CorsConfiguration config = new CorsConfiguration();
        config.setAllowCredentials(true); // 允许携带Cookie等凭证
        config.addAllowedOrigin("https://your-trusted-frontend.com"); // **关键：不要用“*”**
        config.addAllowedHeader("*"); // 允许所有头，根据实际情况可以收紧
        config.addAllowedMethod("*"); // 允许所有方法，根据实际情况可以收紧
        config.setMaxAge(3600L); // 预检请求缓存时间
        source.registerCorsConfiguration("/api/**", config); // 仅对API路径生效
        return new CorsFilter(source);
    }
}

重要警告 ： config.setAllowCredentials(true) 和 config.addAllowedOrigin("*") 是互斥的。如果允许凭证，则必须明确指定允许的来源（ AllowedOrigin ），不能使用通配符“*”。否则浏览器会拒绝请求。这是很多开发者容易踩的坑。

7. 关键安全配置五：敏感信息管理与环境隔离

硬编码在配置文件中的数据库密码、API密钥是安全的大忌。必须将敏感信息与代码分离。

7.1 使用环境变量或配置中心

最基础的做法是使用环境变量。

# application.yml
spring:
  datasource:
    url: ${DB_URL:jdbc:mysql://localhost:3306/mydb} # 优先从环境变量DB_URL读取
    username: ${DB_USER:root}
    password: ${DB_PASSWORD:} # 生产环境务必通过环境变量传入

在启动应用时传入环境变量：

DB_PASSWORD=yourStrongPassword!123 java -jar your-app.jar

对于更复杂的微服务架构，推荐使用配置中心，如Spring Cloud Config、Consul、Apollo等，实现配置的集中管理、加密和动态刷新。

7.2 加密敏感配置属性

Spring Cloud Config Server支持对称加密和非对称加密。你也可以使用本地加密库，如Jasypt。

<!-- pom.xml 添加Jasypt依赖 -->
<dependency>
    <groupId>com.github.ulisesbocchio</groupId>
    <artifactId>jasypt-spring-boot-starter</artifactId>
    <version>3.0.5</version>
</dependency>

# application.yml
some:
  encrypted:
    property: ENC(加密后的字符串) # 用ENC()包裹

jasypt:
  encryptor:
    password: ${JASYPT_ENCRYPTOR_PASSWORD} # 加密密码从环境变量获取

7.3 实操心得：配置文件的分级管理

利用Spring Boot的Profile特性，将不同环境的配置彻底分离。

application.yml ：通用配置，基础设置。
application-dev.yml ：开发环境配置，可包含内存数据库、详细日志等。
application-test.yml ：测试环境配置。
application-prod.yml ：生产环境配置， 绝对不能包含任何真实密码或密钥 ，只包含指向环境变量或配置中心的引用。

激活Profile可以通过环境变量 SPRING_PROFILES_ACTIVE=prod ，或者在启动命令中指定 --spring.profiles.active=prod 。 确保生产环境的Profile激活命令不会意外泄露。

8. 关键安全配置六：输入验证与输出编码

这是防御注入攻击（如SQL注入、XSS、命令注入）的第一道和最后一道防线。

8.1 使用Bean Validation进行声明式验证

在Controller层或DTO层使用JSR-380（Bean Validation 2.0）注解进行输入验证。

@RestController
@RequestMapping("/api/users")
@Validated // 类级别注解，开启方法参数验证
public class UserController {

    @PostMapping
    public ResponseEntity<User> createUser(@Valid @RequestBody UserCreateDTO userDTO) {
        // 如果userDTO验证失败，会抛出MethodArgumentNotValidException
        // ... 创建用户逻辑
        return ResponseEntity.ok(savedUser);
    }

    @GetMapping("/{id}")
    public ResponseEntity<User> getUser(@PathVariable @Min(1) Long id) {
        // 验证路径变量id必须大于等于1
        // ... 获取用户逻辑
    }
}

// DTO示例
public class UserCreateDTO {
    @NotBlank(message = "用户名不能为空")
    @Size(min = 3, max = 20, message = "用户名长度必须在3-20之间")
    private String username;

    @Email(message = "邮箱格式不正确")
    @NotBlank
    private String email;

    @Pattern(regexp = "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)[a-zA-Z\\d@$!%*?&]{8,}$",
             message = "密码必须至少8位，包含大小写字母和数字")
    private String password;
    // getters and setters
}

记得在全局异常处理器中处理 ConstraintViolationException 和 MethodArgumentNotValidException ，返回格式友好的错误信息，而不是暴露堆栈详情。

8.2 输出编码：对抗XSS的最终手段

即使有CSP，对用户可控的数据进行输出编码也是好习惯。在渲染视图时（如Thymeleaf、FreeMarker），模板引擎通常会自动进行HTML转义。

Thymeleaf ：默认所有文本都会进行HTML转义。如果你确实需要输出原始HTML（比如富文本编辑器内容），可以使用 th:utext ，但必须确保该内容在存储前已经过安全的净化处理（如使用Jsoup库）。
返回JSON的API ：问题通常出在前端。确保前端在将API返回的数据插入DOM时，使用安全的API，例如：
- Vue.js：使用 {{ }} 插值或 v-text 指令会自动转义。避免使用 v-html ，除非你完全信任内容来源。
- React：在JSX中使用 {data} 会自动转义。使用 dangerouslySetInnerHTML 是危险的，需慎用。
- 纯JavaScript：使用 textContent 而不是 innerHTML 。

8.3 实操心得：SQL注入的“免死金牌”

使用Spring Data JPA、MyBatis Plus等ORM框架时，只要坚持使用其提供的参数化查询或命名查询，基本上可以免疫SQL注入。

Spring Data JPA ：使用方法名衍生查询或 @Query 注解，框架会处理参数绑定。

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    // 安全
    User findByUsername(String username);
    
    // 安全，使用参数绑定
    @Query("SELECT u FROM User u WHERE u.email = :email")
    User findByEmail(@Param("email") String email);
    
    // **危险！绝对不要这样做！**
    // @Query("SELECT u FROM User u WHERE u.username = '" + username + "'")
    // User findByUsernameUnsafe(String username);
}

MyBatis/MyBatis Plus ：在XML映射文件或注解中使用 #{} 进行参数绑定。

<!-- 安全 -->
<select id="selectUser" resultType="User">
    SELECT * FROM user WHERE username = #{username}
</select>

<!-- 危险！会引起SQL注入 -->
<select id="selectUserUnsafe" resultType="User">
    SELECT * FROM user WHERE username = '${username}'
</select>

核心原则：永远不要通过字符串拼接来构造SQL语句。

9. 关键安全配置七：日志、监控与健康端点安全

日志可能泄露敏感信息，而监控端点如果暴露，则可能成为攻击者侦察和攻击的入口。

9.1 安全地记录日志

避免在日志中记录密码、完整令牌、身份证号、银行卡号等敏感信息。使用日志脱敏工具或模式。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Service
public class PaymentService {
    private static final Logger log = LoggerFactory.getLogger(PaymentService.class);

    public void processPayment(PaymentRequest request) {
        // 错误示例：泄露卡号
        // log.info("Processing payment for card: {}", request.getCardNumber());

        // 正确示例：脱敏后记录
        String maskedCard = maskCardNumber(request.getCardNumber());
        log.info("Processing payment for card ending with: {}", maskedCard);
        // ... 处理逻辑
    }

    private String maskCardNumber(String cardNumber) {
        if (cardNumber == null || cardNumber.length() < 4) {
            return "****";
        }
        return "****-****-****-" + cardNumber.substring(cardNumber.length() - 4);
    }
}

同时，确保生产环境的日志级别不低于 WARN ，避免输出大量调试信息。可以通过Profile来配置：

# application-prod.yml
logging:
  level:
    root: WARN
    com.yourcompany: INFO # 你的业务包可以保持INFO

9.2 保护Actuator和其他管理端点

Spring Boot Actuator提供了丰富的监控和管理端点（如 /actuator/health , /actuator/info , /actuator/metrics , /actuator/env 等）。在生产环境中，必须严格保护这些端点。

# application-prod.yml
management:
  endpoints:
    web:
      exposure:
        include: health,info # 只暴露最安全的端点，如健康检查和基础信息
      base-path: /internal/actuator # 修改默认路径，增加隐蔽性
  endpoint:
    health:
      show-details: never # 健康检查详情永远不显示，或设置为`when-authorized`
    env:
      enabled: false # 禁用env端点，它可能暴露所有配置（包括密码！）
    beans:
      enabled: false # 禁用beans端点

更重要的是，通过Spring Security限制访问：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
            .antMatchers("/actuator/health", "/actuator/info").permitAll() // 健康检查允许所有人访问（或仅限监控系统IP）
            .antMatchers("/actuator/**").hasRole("ACTUATOR_ADMIN") // 其他所有Actuator端点需要特定角色
            // ... 其他URL规则
        .and()
        .httpBasic(); // 为管理端点启用HTTP Basic认证（也可集成到主认证流程）
}

9.3 实操心得：健康检查的“假健康”与“慢响应”

/actuator/health 端点默认会聚合所有已配置的健康指示器（如数据库、磁盘空间、Redis等）。这里有两个坑：

第三方服务健康导致应用不健康 ：如果你的应用强依赖一个外部服务（如邮件服务器、短信网关），当该服务宕机时，会导致整个应用的健康状态为 DOWN ，这可能触发不必要的告警或Pod重启。可以考虑为这类“非核心”依赖创建自定义的健康指示器，并将其设置为不影响整体状态。

@Component
public class ThirdPartyServiceHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        // 检查第三方服务
        boolean isUp = checkService();
        if (isUp) {
            return Health.up().withDetail("message", "Service is available").build();
        } else {
            // 返回down，但不影响整体状态？实际上会影响。更好的做法是将其归为另一个端点。
            // 或者，在management.health.status.order配置中调整权重。
            return Health.down().withDetail("error", "Service unavailable").build();
        }
    }
}

健康检查响应慢 ：如果健康检查需要连接数据库、Redis等，网络波动或服务慢可能导致健康检查超时。 务必为健康检查端点配置独立的、较短的超时时间 （在负载均衡器或Kubernetes的探针配置中设置），并确保健康检查的逻辑尽可能简单、快速。一个常见的做法是让健康检查只检查应用本身是否存活，而不检查所有外部依赖。

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

在实际配置和运维过程中，总会遇到一些“诡异”的问题。这里记录几个我印象深刻的案例和排查思路。

10.1 问题：用户登录成功，但后续请求依然被重定向到登录页。

排查步骤 ：
1. 检查会话Cookie ：打开浏览器开发者工具，查看登录后是否成功设置了 JSESSIONID Cookie。检查其 Path 、 Secure 、 HttpOnly 、 SameSite 属性是否正确。如果 Path 不是应用根路径 / ，可能导致Cookie不被发送。
2. 检查上下文路径 ：如果你的应用部署在非根路径（如 /app ），而Spring Security的配置没有考虑这一点，登录成功后的默认跳转路径可能出错。确保在 SecurityConfig 中配置了正确的上下文路径，或者使用相对路径。
3. 检查CSRF ：如果是POST请求，检查是否包含了CSRF令牌。对于表单登录，Spring Security会自动添加。对于API请求，如果误开启了CSRF，则需要手动在请求头（如 X-CSRF-TOKEN ）或参数中携带令牌，或者确认是否需要禁用CSRF。
4. 查看日志 ：开启Spring Security的调试日志 logging.level.org.springframework.security=DEBUG ，可以看到详细的认证和授权决策过程，非常有用。

10.2 问题：配置了CORS，但前端请求依然报跨域错误。

排查步骤 ：
1. 检查 Access-Control-Allow-Origin 头 ：确认响应头中的值是否精确匹配前端发起请求的 Origin （协议+域名+端口）。 严禁使用通配符 * ，尤其是在 allowCredentials 为 true 时。
2. 检查预检请求 ：对于非简单请求（如Content-Type为 application/json 的POST请求），浏览器会先发送一个 OPTIONS 方法的预检请求。确保你的CORS配置和Spring Security配置允许 OPTIONS 方法通过，并且在这个阶段也返回正确的CORS头。
3. 检查Spring Security过滤器链顺序 ：确保CORS过滤器在Spring Security过滤器链之前执行。通常使用 @Bean 定义的 CorsFilter 会自动排在靠前的位置。如果自定义了 WebSecurityConfigurerAdapter ，可以在 configure(HttpSecurity http) 中通过 http.cors() 来启用默认配置。
4. 浏览器网络面板 ：仔细查看浏览器开发者工具中“网络”标签页下，出错请求和预检请求的请求头和响应头，比对差异。

10.3 问题：生产环境密码已通过环境变量设置，但应用启动时报错找不到密码。

排查步骤 ：
1. 检查环境变量名 ：确保在部署环境（如Docker容器、Kubernetes Pod、服务器系统）中设置的环境变量名与 application.yml 中引用的占位符（如 ${DB_PASSWORD} ）完全一致，包括大小写。
2. 检查环境变量的作用域 ：在Linux系统中，检查是在哪个shell中设置的环境变量，以及启动Java进程的用户是否能继承到这个环境变量。最好在启动脚本或系统服务文件中显式设置。
3. 检查Spring Profile ：确认生产环境的Profile（如 prod ）已正确激活。有时 application-prod.yml 中的配置因为Profile未激活而未被加载。
4. 使用调试模式 ：在启动命令中添加 --debug 参数，查看Spring Boot的配置报告，确认最终生效的配置属性源和值是什么。

10.4 问题：使用了 @PreAuthorize 注解，但权限控制不生效。

排查步骤 ：
1. 确认注解已启用 ：检查配置类上是否添加了 @EnableGlobalMethodSecurity(prePostEnabled = true) 。 @PreAuthorize 需要 prePostEnabled = true 。
2. 确认代理模式 ：Spring AOP默认使用JDK动态代理，这要求被代理的类必须实现接口。如果 @Service 类没有实现接口，Spring会使用CGLIB代理。确保你的配置支持CGLIB（通常默认是支持的）。一个更稳妥的方法是在注解上明确指定： @EnableGlobalMethodSecurity(prePostEnabled = true, proxyTargetClass = true) 。
3. 检查方法调用是否经过代理 ：在同一个类内部的方法A调用方法B，方法B上的 @PreAuthorize 会失效，因为内部调用绕过了代理对象。这是AOP的常见问题。需要通过依赖注入自身代理或调整代码结构来解决。
4. 检查SpEL表达式 ：仔细检查 @PreAuthorize 中的表达式语法是否正确，引用的Bean名称、方法参数名是否匹配。表达式中的 authentication 对象是Spring Security自动注入的。

安全配置是一个持续的过程，而不是一劳永逸的设置。这7个关键配置为你构建了一个坚实的起点，但真正的安全还依赖于依赖库的及时更新、定期的安全扫描、代码审查以及团队的安全意识。每次引入新的框架或功能时，都记得问一句：“这会对现有的安全配置产生什么影响？” 多问这一句，也许就能避免一次严重的安全事件。