Spring Security这5个坑

去年有个团队找我做代码审计，他们的安全配置看起来无懈可击——JWT过滤器、BCrypt加密、完整的SecurityFilterChain。我花了整整两天逐行核对，最后在一个角落发现了问题：/api/admin/users被URL模式保护着，但返回完全相同数据的/api/users/all却完全暴露。这就像给豪宅装了防弹门，却在地下室留了条没上锁的隧道。

坑1：以为依赖到位=安全到位

很多开发者把spring-security加进pom.xml，配几个URL白名单，就觉得任务完成。但安全配置不是超市购物——东西放进购物车不代表结账成功。 senior dev的习惯是：每加一个端点，手动验证一次权限拦截，而不是相信配置文件的"看起来覆盖了"。

那个团队的admin接口和public接口用了不同的命名风格，导致通配符匹配时漏掉了一半。URL模式配置就像正则表达式，写的时候很自信，跑的时候很意外。

坑2：过滤器链顺序盲盒

Spring Security的过滤器链（Filter Chain）是按顺序执行的，但很多人把它当黑箱用。我见过JWT验证过滤器被放在权限检查之后——结果未登录用户直接绕过了令牌校验，却在权限判定环节因为"匿名用户"被拦截。功能上没漏洞，但逻辑顺序让人血压飙升。

senior dev会画一张过滤器执行顺序图，确认每个请求的完整路径。这不是过度设计，是把隐式依赖变成显式检查。

坑3：密码学配置复制粘贴

BCryptPasswordEncoder用了，但work factor（工作因子）用的是默认值？2024年的默认参数可能是2014年写的。加密强度不是"用了就行"的二元问题，是"够不够用"的定量问题。安全公告里的CVE编号不会因为你"用了行业标准算法"就放过你。

那个审计项目的BCrypt强度参数还是10，而OWASP当前建议至少12。3年的技术债，在安全领域就是裸奔。

坑4：测试用例里的安全幻觉

我见过太多项目的安全测试只有一条：用正确凭据登录，期望200；用错误密码，期望401。这测的是Spring Security有没有装，不是你的配置有没有漏。 senior dev会写"横向越权测试"——用用户A的令牌访问用户B的资源，期望403。

安全测试的覆盖率，和漏洞发现的概率，是线性关系。不是"测了就行"，是"测到位才行"。

坑5：把安全当功能而非流程

那个漏掉的/api/users/all端点，是在一次"紧急需求"里加的。产品经理要快速上线，开发说"就加个查询接口"，没人想起要同步更新安全配置。安全不是代码层面的属性，是变更管理流程的副产品。

senior dev的习惯很简单：任何端点变更必须同步更新安全文档，任何配置修改必须有双人review。不是不信任，是知道人会在凌晨3点的紧急发布里犯错。

代码审计结束后，那个团队问我：这种漏洞能不能靠工具自动发现？我说能，但工具不会告诉你为什么当初会漏掉——是命名不规范？是review流程缺失？还是测试策略的盲区？安全债务和技术债务一样，利息越滚越高，而还款日通常是出事那天。

你的项目最后一次完整的安全配置审计是什么时候？