搞懂Web垂直越权防护，别让普通用户改动后台核心数据

垂直越权这事儿吧，听起来玄乎但离咱们开发岗甚至产品岗都不算远。很多人都觉得，普通用户只能看到自己的订单、自己的积分，后台的功能他们根本摸不到边，其实不然。 你有没有见过这种离谱的场景？用户A登录自己的外卖平台，把订单ID从1改成2，瞬间看到了用户B昨天刚点的带地址带备注隐私的外卖单子？或者普通账号输入一串带老板ID的URL，直接能给全公司发全员通知？这些都是没做好垂直越权闹的。说白了就是同一个系统里，低权限角色钻了「身份/权限校验只在前端做的空子，直接访问甚至篡改高/不同高身份的数据。 很多小团队最容易踩的坑？第一个就是把所有权限判断全塞前端，后端当“甩手掌柜”。以为前端加个按钮隐藏就完事，谁知道懂点技术的小白，F12打开控制台，删个display:none或者改个请求参数里的ID，分分钟就进去了。这个坑踩不得，前端的所有展示、按钮、请求都可以被破解，必须把后端权限校验焊死在每个需要验证身份才能进的接口里。 那怎么焊？得明确两个核心步骤，先验身份，再查身份对应的权限，两个缺一不可。 举个生活化的例子，你去取快递，驿站老板第一先看你手机尾号对不对（验身份），第二再看是不是你报的取件码和你手机里的快递是不是你的专属件（查权限），尾号对了但件不对，根本不会给你，放到系统里就是这个理。 后端的逻辑就是，不管前端发过来的请求，不管有没有ID是啥，先看请求头里的token或者session是不是当前登录用户的有效凭证，有效了之后，再把请求的目标数据关联的用户ID（或者角色对应的权限范围）和当前登录的用户ID（角色）做对比，对不上直接返回403 Forbidden就行。 还有一个常见的漏洞触发点，是数据查询的时候忘了加当前用户的过滤条件。很多写SQL写顺手了，直接写SELECT FROM orders WHERE order_id = {orderId}，这就相当于给别人递了门钥匙。正确的SQL应该是SELECT FROM orders WHERE order_id = {orderId} AND user_id = {currentUserId}，这样不管别人怎么改orderId，查出来的永远是自己的东西。 别小看这个加过滤条件，很多大厂早期都踩过这个低级但致命的坑，之前某电商大厂实习生做订单查询功能，漏加了这个条件，上线当天就被灰产抓了漏洞，爬了几十万用户的地址信息。 还有一种更隐蔽的垂直越权，是功能接口没有加权限验证的层级限制。比如普通用户只能提交自己的评价，却可以修改管理员审核评价的接口？比如系统只在前端显示“审核按钮管理员可见”，但提交审核结果的接口根本没判断当前登录用户是不是管理员，普通用户直接构造POST请求，把不合格的评价改成已通过，那就乱套了。这种情况要注意，每个功能接口，尤其是增删改这种高危接口，都要单独加一次权限验证，不能偷懒。 最后提个醒，做完垂直越权防护之后，一定要自己多测测。怎么测？用自己的普通账号登录，拿到token或者cookie，然后修改请求参数里的用户ID、角色ID、资源ID，看看能不能访问或修改别人的东西，或者直接在Postman或者Apifox里构造不带身份凭证的请求，看看会不会被拦截。如果自己测不出来，可以找身边懂安全的朋友帮忙，或者用一些开源的安全扫描工具扫一下，别等上线了被黑客发现了才后悔莫及。