凌晨三点，前后我盯着屏幕上那条报错日志，台漏后背发凉。前后用户ID字段里躺着一串SQL注入语句，台漏居然没被过滤——前端明明做了严格的前后输入校验，可数据还是台漏穿透了。这不是前后黑客高明，是台漏前后台各管各的，中间留了道缝。前后

很多团队把安全当接力赛。台漏前端负责拦，前后后端负责查。台漏可现实是前后，前端觉得“我都校验过了”，台漏后端觉得“前端都拦住了”，前后结果两边都松手。去年某电商平台搞促销，前端限购逻辑写得滴水不漏，每个账号最多买两件。结果黄牛直接调接口，绕过页面，批量下单几千件。前端再严，管不到后台API。这就像给大门上了十把锁，却把后门钥匙挂在墙上。

更常见的是权限漏洞。后台管理页面藏在URL的/admin路径下，前端菜单没显示入口，就以为安全了。可搜索引擎爬虫、目录扫描器，分分钟就能找到。我见过一个内部系统，修改用户角色的按钮在前端被隐藏了，但接口还活着。有人用浏览器开发者工具改了下HTML，把display:none删掉，按钮就出现了，点一下，自己成了管理员。你说这是前端漏洞还是后台漏洞？都不是，是没人想过“前端隐藏不等于后台拒绝”。

还有个真实案例。某银行App的转账功能，前端限制单笔不超过5万。风控人员觉得有这层限制就稳了。结果有人抓包，把请求里的金额字段从50000改成500000，后端居然没再验证一次。那笔钱转出去了，追回来花了三个月。前端校验是为了用户体验，不是安全边界。真正的安全判断，必须发生在后台，而且后台要假设所有前端数据都不可信。

但后台也不是万能的。有些后台逻辑复杂，参数一多就容易漏。比如一个修改订单的接口，前端只传了订单号和金额，后台却默认用户身份从Session里取。可如果另一个接口允许用户修改自己的Session里的角色值呢？串联起来，就是一条完整的提权路径。这种问题，靠前后端各自自查根本发现不了，得有人站在整个系统的高度去捋数据流。

我见过最讽刺的画面，是安全团队给前端配了最贵的WAF，给后台加了双因子认证，结果开发在代码注释里写了数据库连接密码。密码是硬编码的，前端打包后，JS文件里能看到。你猜怎么着？有人用这个密码直接连了生产库，把用户表导出，然后删库跑路。前后台漏洞再多，也敌不过这种“人祸”。

说白了，前后台漏洞不是技术问题，是责任划分问题。前端别觉得自己只是展示层，后台别觉得前端挡了就没自己的事。每一条数据，从浏览器到服务器，每一跳都得重新审视。你问我怎么防？我没什么高招，就是让前端把能想到的校验都做了，后台再把所有校验都重做一遍，然后两拨人坐在一起，互相挑刺——拿真实攻击案例做演练，把对方负责的模块当敌人。只有这样，那道缝才能被看见。