后台登录页我加了验证码和限流，却漏了最蠢的一关：返回包里把管理员ID明文塞进了前端

上周帮朋友看一个被挂马的老站，登录后台扫了一圈，验证码、IP限流、密码错误锁定都有，看着挺像回事。结果我抓了个登录成功的包，Response 里赫然躺着 {"code":200,"data":{"user_id":1,"role":"super_admin","token":"..."}}。

就这？前端 Vue 拿到数据往 store 一丢，路由守卫判断 role === 'super_admin' 直接放行。我当场乐了——这等于把钥匙挂在门把手上，门装的是银行金库的厚度。

这事让我重新捋了遍后台鉴权的几个"看起来做了、其实白做"的坑，全是血泪：

一、前端鉴权是纸糊的，后端必须每条接口重新验

太多人把角色判断写在前端，菜单隐藏、按钮禁用，以为眼不见就安全。实际上我右键检查改个 display:none，或者直接 curl 调接口，前端那些花活全废。正确的姿势：前端只做 UI 适配，后端每个接口进来先验 token、再查库确认用户状态（是否禁用、角色是否变动），最后才谈业务逻辑。

二、Token 别只验"有没有"，要验"对不对、活没活"

我见过最离谱的实现：中间件里 if (!empty($token)) { return true; }，只要带了 token 字符串就放行，不管是不是瞎编的。还有把 token 当 session 用，生成完扔 Redis 却从不设过期时间，用户退出清的是本地缓存，Redis 里那条能活到服务器重启。

现在我的习惯是双 token（access + refresh），access 15 分钟过期，每次用顺便续命；refresh 7 天但只能换 access，不能进业务。退出时把两个都拉黑，Redis 里记个黑名单集合，中间件先查黑再验白。

三、CSRF 防护别只依赖 SameSite，关键操作要二次确认

SameSite=Lax 能挡 90% 的跨站 POST，但 GET 请求它不管啊。我之前有个删除接口图省事用的 GET /admin/user/del?id=123，结果内网里被人嵌了个 <img src="http://admin.xxx.com/admin/user/del?id=123">，管理员一点开邮件，用户没了。

现在强制规范：敏感操作全 POST + 表单 token（前后端分离就带 X-CSRF-Token 或自定义 Header），删除改状态前先弹窗确认，重要操作加短信或邮箱二次验证。别嫌烦，真出事了更烦。

四、SQL 注入防了拼接，没防"合法"的恶意参数

ThinkPHP 的查询构造器确实能挡 ' OR '1'='1 这种，但我见过更隐蔽的：接口接收 order=price desc 直接拼进 ->order($order)，攻击者传 price desc;drop table admin--，框架以为 order 是字符串，数据库可不这么想。还有 field() 里传用户可控的字段名，whereRaw() 里拼接条件，都是雷。

我的做法：排序字段白名单化，只允许预定义的几个；field 用数组限定；万不得已用 whereRaw 时，参数必须绑定，打死不拼接。

五、最蠢也最常见：接口返回了不该返回的字段

开头说的那个 user_id 和 role 明文返回只是冰山一角。我还见过返回用户列表带密码哈希（虽然是 md5）、返回订单详情带用户完整手机号、返回文章列表带删除标记的软删除字段。ThinkPHP 的 hidden 和 visible 要用熟，API 输出前过一遍 toArray() 再手动滤一遍敏感字段，双重保险。

另外日志里也注意，别为了方便调试把请求参数全打进去，万一参数里有密码、token，日志泄露就是二次伤害。

——

写完这些发现，安全这事和减肥一样，都知道原理，难的是每条接口、每个字段都执行到位。我现在上线前会过一遍 checklist：接口鉴权验了吗？返回字段滤了吗？敏感操作加验证了吗？日志脱敏了吗？

你们有没有类似"以为做了其实漏了"的鉴权翻车经历？欢迎丢出来一起复盘，我这边案例库还能再厚点。