去年秋天，网站鉴权我帮一个做独立博客的网站鉴权朋友查问题。他的网站鉴权网站流量不大，但每天都有几十条奇怪的网站鉴权注册记录，邮箱全是网站鉴权随机字符串。他问我：“是网站鉴权不是被爬虫盯上了？”我登进后台看了一眼，发现注册接口根本没有频率限制，网站鉴权也没有验证码。网站鉴权更离谱的网站鉴权是，登录接口返回的网站鉴权错误信息里直接写着“用户名不存在”或“密码错误”——这等于给攻击者送了一份用户名枚举指南。

这就是网站鉴权典型的鉴权漏洞。很多人把“鉴权”和“认证”混在一起说，网站鉴权其实两件事。网站鉴权认证解决“你是网站鉴权谁”，鉴权解决“你能干什么”。网站鉴权你拿身份证进小区，保安看照片确认是你，这是认证。进楼之后，你只能刷开自己那一层，刷不开别人家，这是鉴权。网站也一样，登录只是第一步，登录之后每个接口、每个资源，都得再问一遍：这个用户有没有权限碰这个东西？

我见过最粗暴的鉴权实现，是在URL里带一个role=admin参数。前端发请求时带上，后端读这个参数决定给不给数据。攻击者把role改成admin，直接拿到管理后台的全部用户列表。这种写法现在听起来荒唐，但早年不少小系统真这么干。根源在于把鉴权交给了客户端——客户端是用户的领地，用户想怎么改就怎么改。

正确的做法是服务端自己记住每个用户的身份和权限。用户登录成功后，服务端生成一个令牌（比如JWT或者session ID），后续请求带着这个令牌来，服务端从令牌里解析出用户ID，再去数据库查这个用户有什么角色、能访问哪些资源。整个过程不信任请求里任何关于“我是谁”“我是什么角色”的声明。

但光有令牌还不够。我另一个做电商的朋友踩过坑：他用JWT做鉴权，令牌里写了userId和isAdmin。问题是他把JWT的签名密钥硬编码在前端代码里了。任何人打开浏览器开发者工具，都能拿到密钥，然后自己签一个isAdmin: true的令牌。JWT本身没问题，问题出在密钥管理上。密钥必须留在服务端，前端只负责存令牌、传令牌，不参与签发和验证。

还有一种常见错误是“只检查登录，不检查归属”。比如一个查订单的接口/api/order/123，用户登录了就能访问。但用户A登录后把123改成124，就能看到用户B的订单。这叫水平越权。修复方法很简单：查订单时加一个条件where userId = 当前登录用户ID。可就是这么简单的事，很多团队在赶工期时漏掉了。

我自己的习惯是，每写一个涉及数据的接口，先问三个问题：这个接口需要登录吗？需要什么角色？这个数据属于当前用户吗？三个问题对应三层检查，缺一层都可能出事。别指望前端做鉴权，前端做的叫“界面控制”，用户看不到按钮不代表他调不了接口。真正的鉴权永远在服务端，在每一次数据库查询之前。

说到底，网站鉴权不是加个登录框就完事了。它是一套贯穿请求生命周期的检查机制，从令牌签发、传输、解析，到每一个资源访问时的归属判断。任何一个环节偷懒，都可能让整个系统变成筛子。我那个博客朋友后来加了频率限制和统一错误提示，注册垃圾账号少了很多。但他真正该做的，是把鉴权逻辑从头到尾捋一遍——可惜大多数人只有被黑之后才愿意干这件事。