系统日志里那行字刺眼得很：用户A在凌晨两点十七分，出现越权成功下载了用户B的出现越权合同附件。A和B分属不同公司，出现越权八竿子打不着。出现越权这不是出现越权黑客攻击，没有漏洞利用，出现越权就是出现越权A登录后台后，手贱改了URL里的出现越权一个数字ID，把“document_id=1024”改成了“1025”。出现越权

越权就这么发生了。出现越权轻飘飘的出现越权，像捅破一层窗户纸。出现越权

我见过太多开发团队把精力砸在SQL注入和XSS上，出现越权防火墙规则写了一长串，出现越权却对越权视而不见。出现越权挺讽刺的——OWASP Top 10里，越权常年霸榜，但真正认真做权限校验的项目，十个里挑不出三个。原因不难猜：测SQL注入有现成工具，扫一眼报告就能交差。越权呢？得靠人肉去猜业务逻辑，去遍历每一个接口的每一个参数。麻烦，而且不出活儿。

有个电商客户，去年被薅了上百万的优惠券。不是机器人刷的，是几个“聪明人”发现领券接口只校验了用户是否登录，没校验这个券是不是发给他的。改个user_id就能领别人的专属券。技术团队复盘时脸都绿了——这个接口上线两年，代码评审过了三轮，愣是没人想过要测越权。

你问为什么没人想？因为写代码的人默认“别人不会这么干”。可现实是，总有闲得慌的人会去点那个“编辑”按钮，然后顺手把URL里的ID改成别人的。人性里那点好奇心，就是越权最好的肥料。

更操蛋的是，越权的危害常常是滞后的。数据被偷看、被篡改，不像服务器宕机那样当场爆炸。等发现的时候，往往已经过了几个月，日志都滚了好几轮，想追溯都无从下手。有个金融客户，用户A能看到用户B的持仓明细，这事存在了半年才被一个较真的用户投诉曝光。半年，够干多少坏事？

我后来养成了个习惯，看一个系统安不安全，先不看它用了什么加密算法，直接翻它的权限校验代码。如果看到那种只判断“是否登录”就开始处理业务的地方，心里基本就有数了。再往后翻，如果连个“当前用户ID是否等于资源所属用户ID”的if判断都没有，那这系统基本就是穿着裤衩在裸奔。

修起来难吗？说难也难，说简单也简单。难在要梳理清楚每一个资源的归属关系，简单在只要在每个接口入口处加一行校验代码。可就是这行代码，总被遗忘在角落。因为写业务逻辑时，人脑里装的是“功能要跑通”，不是“谁能碰这个功能”。

那天凌晨两点十七分的日志，后来被安全团队截下来当成了培训教材。PPT上写着“越权检测方法”，底下坐着的人，有几个在打哈欠。我猜他们心里想的是：这玩意儿，改个ID就能测出来，还用专门教？可就是这种“简单”的漏洞，每年让多少企业赔钱、道歉、下架整改。你永远不知道下一个手贱改ID的人是谁，但你能确定，他一定存在。