去年秋天，分享漏洞我帮一个做电商的分享漏洞朋友看服务器日志。他卖手工皮具，分享漏洞网站不大，分享漏洞每天几百单。分享漏洞翻到凌晨三点的分享漏洞记录时，我发现一个奇怪的分享漏洞请求：有人用脚本批量提交优惠券码，每次只改最后一位，分享漏洞像在试钥匙。分享漏洞

朋友说那批券早过期了。分享漏洞但脚本没停，分享漏洞还在跑。分享漏洞我顺着IP查下去，分享漏洞发现对方在试探一个更老旧的分享漏洞接口——那是两年前临时上线的活动页面，早该下线，分享漏洞却一直挂在服务器上。接口没做频率限制，也没校验用户身份，只要参数对，就能无限次查询任意订单的收货地址和电话。

这就是典型的“分享漏洞”。不是那种惊天动地的零日，而是被人遗忘的角落。开发时图快，上线后忘了关，像家里装修时在墙上留了个洞，以为迟早会补，结果三年过去，洞还在，风一直灌进来。

我见过太多这类事。前年某在线教育平台，一个分享链接能直接跳到后台管理页，只因为前端路由没做权限拦截。去年一个社区团购小程序，分享给好友的砍价页面，把用户ID明文写在URL里，改个数字就能看别人的订单。这些漏洞有个共同点：它们都藏在“分享”这个动作里。分享本是好事，拉新、传播、裂变，但分享出去的链接往往带着参数、带着身份、带着不该暴露的入口。

有人觉得小漏洞无所谓。反正没数据泄露，没资金损失。可攻击者不这么想。他们像捡贝壳的人，沿着海岸线慢慢走，专挑那些半埋在沙里的。一个漏洞可能只泄露一个手机号，但一万个漏洞拼起来，就是一张完整的用户画像。更麻烦的是，这些漏洞往往互相串联。先用A接口拿到用户ID，再用B接口查订单，最后用C接口改地址。每一步都看似无害，合起来就是一场精准诈骗。

我自己的习惯是，每次上线新功能，先问一句：这个页面分享出去，别人能看到什么？能改什么？如果答案里有“好像能改”，那就得停下来。很多团队缺的不是技术，是这种“多问一句”的惯性。开发赶进度，产品催上线，测试只跑主流程。那个被遗忘的接口，就像聚会结束后留在桌上的半杯酒，没人记得它，但它一直在那儿。

修复其实不复杂。把老接口下线，加个频率限制，或者干脆在网关层统一鉴权。难的是发现它。我后来给朋友写了个脚本，每天扫一遍所有对外接口，看哪些返回了不该返回的字段。跑了一周，又揪出两个类似问题。其中一个接口甚至能返回其他用户的身份证号前六位——那是两年前做实名认证时留下的，早没人维护。

分享漏洞不会自己消失。它们只会随着代码迭代越埋越深。每次重构、每次迁移，都可能把它们带到新环境里。你不去找，它们就安静地待着，直到某天被人翻出来。那时候再补救，成本就不是几行代码的事了。

所以我现在看一个系统安不安全，不看它有多少防火墙，看它有多少被遗忘的接口。那些没人记得的角落，才是真正的入口。