老张的台前台验电商后台，密码试了三次就被锁了。证绕他换了个思路，过逻把请求里的辑漏userid=1024改成userid=1，结果直接进了管理员面板。台前台验这不是证绕什么高深黑客技术，就是过逻web平台前台验证绕过——前端只管拦，后端不设防。辑漏

这类漏洞的台前台验核心逻辑特别简单：开发人员默认“用户看不到的接口就是安全的”。比如一个修改个人资料的证绕页面，前端表单只允许填昵称和头像，过逻但抓包一看，辑漏提交的台前台验数据包里还藏着role=user字段。把user改成admin再发出去，证绕服务器端居然照单全收。过逻你说这算不算把钥匙挂在门口，还特意在门牌上写了“备用钥匙”三个字？

更常见的场景是验证步骤跳转。有个朋友做过一次众测，目标是个支付系统。下单后跳到收银台，前端JS判断“余额不足”就弹出提示并终止流程。他直接把支付接口的响应码从fail改成success，再用代理工具重放一遍请求——订单状态硬生生被掰成了已支付。后来查代码才发现，后端只校验了请求签名，根本没校验支付网关的回调结果。这就像快递员敲门说“包裹到了”，你连门都没开就签收了。

还有个案例发生在登录环节。某平台用手机验证码登录，前端把验证码明文存在了localStorage里，方便“用户下次自动填充”。攻击者只要用XSS脚本读一下本地存储，就能拿到验证码直接登录任意账号。这哪里是验证，分明是给攻击者递刀子。

绕过手法五花八门，但根子都是一样的：把安全决策交给了不可信的客户端。前端验证本质上是用户体验优化，不是安全边界。真正的防线必须放在服务器端——校验参数类型、校验业务状态、校验权限归属。可惜很多开发团队为了赶工期，把登录状态、权限判断全写在JS里，后端接口裸奔得像没穿裤子的醉汉。

我见过最离谱的一次，某个管理后台的删除操作接口，只检查了URL里有没有token参数，压根不验证token归属。随便拿个用户token，把请求路径从/api/user/delete改成/api/admin/delete，权限直接拉满。这种漏洞连扫描器都懒得报，因为太基础了——但就是能打通。

修复方案其实不复杂。前端校验保留，但后端必须独立做二次校验：用户身份从session或签名中取，不信任任何请求体里的字段。状态变更类操作，要校验当前状态是否合法。敏感操作加个一次性nonce，防重放。最后，安全测试别光测功能，得专门测“反着来”的场景——把参数改坏、跳步操作、伪造响应码。

老张后来怎么解决的？他让后端加了中间件，统一校验每个接口的权限映射表，前端传什么角色都不认，只认登录时签发的JWT里的角色声明。半个月后，那个绕过漏洞再没出现过。道理就这么简单——别让用户替你决定他是什么人。