认证这件事，感觉上早就被解决了——直到你接手一个其实没解决好的代码库。开始重写 Leverage OJ 的时候，我发现认证系统其实是三个问题穿了一件外套：一个在 PM2 下会出问题的 Session 配置、一个演变成独立平行宇宙的 ContestUser 认证体系、以及一套差一次配置泄露就会全库密码暴露的哈希方案。

这些问题都不是一眼能看出来的。系统在运行——用户可以登录，Session 能持久化，比赛能正常进行。但"能运行"和"正确"是两回事，看得越仔细，就越能看到一个基于不再成立的假设运转的系统。

Session 哪里出了问题

向生产应用新增 50+ 个 endpoint，你不只是有了一个新功能，而是有了一个新的攻击面。Leverage OJ 后端重写几乎改动了系统里的每一个路由，引入了新的角色层级体系，并替换了整个认证层。这类改动正是会产生权限 bug 的地方：旧系统里生效的访问控制，要么没有移植过来，要么移植错了。

上线前我们做了系统性的安全审计。这篇文章记录审计方法和发现的问题——包括一个会让错误用户触发代码重评测的回归 bug，以及一个在生产环境没有任何访问控制、静静存在多年的 FIXME 注释。

背景：发生了什么变化

原来的 Leverage OJ 后端角色结构比较扁平。重写后引入了更清晰的三级层级：