Spring项目始终返回403 Forbidden：登录授权失败求助

你遇到的这个问题真的很典型——不管切换JDBC还是内存认证都返回403，说明问题大概率不在认证源本身，而是卡在授权规则、请求匹配或者安全过滤器链的配置上。我给你梳理几个最值得优先排查的方向：

1. 先检查SecurityFilterChain的授权规则配置 #

这是最容易踩坑的环节，一定要盯紧两点：

• 登录相关的接口必须允许匿名访问（不然连登录请求都被拦截，直接返回403）
• 需要授权的接口，配置的权限要和用户实际拥有的权限完全匹配

举个Spring Security 6+的正确配置示例参考：

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            // 放开登录页、登录提交接口的匿名访问权限
            .requestMatchers("/login", "/auth/login-process").permitAll()
            // 其他所有请求必须经过认证
            .anyRequest().authenticated()
        )
        .formLogin(form -> form
            .loginProcessingUrl("/auth/login-process") // 表单提交的后端接口
            .defaultSuccessUrl("/dashboard") // 登录成功后的跳转页
        );
    return http.build();
}

如果你之前写了.anyRequest().hasRole("ADMIN")但用户只有USER角色，那必然会触发403，这点一定要仔细核对。

2. 确认用户权限的配置逻辑 #

不管用内存还是JDBC认证，用户的权限/角色必须正确设置：

• 内存认证的正确姿势：

@Bean
public UserDetailsService userDetailsService() {
    UserDetails normalUser = User.withUsername("nobalG")
        .password("{noop}your-password") // {noop}表示不加密，生产环境一定要替换成BCrypt等加密方式
        .roles("USER") // roles方法会自动给权限加ROLE_前缀，后续判断要用hasRole("USER")或hasAuthority("ROLE_USER")
        .build();
    return new InMemoryUserDetailsManager(normalUser);
}

• JDBC认证的话，要确保用户表和权限表的关联SQL正确，查询出来的权限字符串是ROLE_xxx格式（比如ROLE_USER），否则权限匹配会失败。

3. 排查CSRF保护的影响 #

Spring Security默认开启CSRF保护，如果你的登录表单没提交CSRF令牌，会被拦截导致认证失败（表现出来就是403）。解决方法：

• 在登录表单里添加CSRF隐藏域：

<input type="hidden" th:name="${_csrf.parameterName}" th:value="${_csrf.token}"/>

• 调试阶段可以临时关闭CSRF（生产环境绝对不建议）：

http.csrf(csrf -> csrf.disable());

4. 验证请求路径的匹配规则 #

有时候我们配置的requestMatchers路径和实际请求路径不匹配，比如实际请求是/api/dashboard但配置的是/dashboard，导致请求被误判为需要授权的资源。可以开启Spring Security的调试日志，直观看到请求的匹配过程：
在application.properties中添加：

logging.level.org.springframework.security=DEBUG

查看日志里FilterChainProxy的输出，就能清楚看到每个请求走了哪些过滤器，以及授权规则的匹配结果。

5. 检查是否有自定义过滤器/拦截器干扰 #

如果项目里有自定义的过滤器或拦截器，可能会在Spring Security的过滤器之前就拦截了请求，或者修改了认证信息，导致后续授权失败。可以暂时禁用这些自定义组件，测试是否能正常登录，以此排查干扰源。

要是上面的步骤还没解决问题，建议把完整的Security配置代码贴出来，能更精准定位根源～

内容的提问来源于stack exchange，提问作者nobalG