2024年3月的网站一个深夜，某知名云服务商的发布监控系统突然弹出红色警报——一个内部代码仓库的访问权限被异常调用。技术人员顺着日志追查，泄密发现攻击者早在两周前就通过一个看似无害的网站“文档分享链接”拿到了入口。那个链接，发布是泄密公司某位工程师为了图方便，把内部设计稿的网站预览权限设成了“任何人可查看”。

这起事故的发布代价是惨重的：源代码被完整下载，其中包括尚未发布产品的泄密核心算法。一周后，网站竞品抢先上线了几乎一模一样的发布功能。讽刺的泄密是，那位工程师的网站本意只是想让客户早点看到设计效果，少开几次沟通会。发布

网站发布泄密，泄密大多数时候不是黑客技术多高明，而是“方便”在作祟。我见过太多团队把内部测试站点直接挂在公网IP上，密码就用“admin123”。更有甚者，把含敏感数据的页面藏在“robots.txt禁止抓取”的路径下，以为搜索引擎看不到就安全了。但任何懂得查看网页源码的人，都能在注释里发现那些被遗忘的链接。

有个案例让我印象极深。某创业公司的官网改版，前端工程师把新旧两版页面都部署到了服务器上，旧版用了一个带“_old”后缀的目录。改版顺利完成，所有人都忘了清理那个目录。三个月后，有用户反馈说在Google搜索里看到了该公司未公布的融资计划书——原来那个“_old”目录里的页面不仅没设密码，还因为带有完整的meta信息被搜索引擎顺利收录了。

这类泄密有个共同特点：发布者完全没意识到自己在“发布”。他们以为只是在“临时放一下”、“测试一下”或者“内部看看”。但互联网没有“临时”这个概念——只要URL能被访问，它就已经在公网上了。哪怕你事后删除了文件，搜索引擎的快照、别人的缓存、甚至浏览器的历史记录都可能留下痕迹。

更麻烦的是，泄密的路径往往不是直线。攻击者不会直接攻击你的官网，而是先攻破你外包供应商的服务器，再通过供应商和你对接时留下的FTP账号摸进来。或者，他们从你员工在技术论坛上发的求助帖里，找到那段贴出来的配置代码——里面恰好写着数据库连接地址和弱口令。

有一次我给一家企业做安全审计，发现他们官网的“联系我们”表单背后，居然连着生产环境的数据库。前台填个名字，后台就能跑SQL查询。开发者的解释是“这样方便实时看客户反馈”。方便，又是方便。

网站发布泄密的本质，是把“内部信息”和“公开信息”的边界擦掉了。这个边界一旦模糊，出事儿只是时间问题。我见过最荒唐的案例，是一家公司把内部员工通讯录做成了网页版，挂在官网子域名下，理由是“方便大家出差时查同事电话”。结果这个子域名没加任何访问控制，被搜索引擎一抓一个准——所有员工的手机号、家庭住址、紧急联系人信息全部暴露。

事后复盘时，那位负责IT的同事说了句大实话：“我以为那个子域名别人发现不了。”
可互联网上，任何URL都是可以被“发现”的。你以为藏在深巷里的门，其实开在大马路上。

现在，我每次看到有人把内部工具顺手部署到公网服务器上，都会想起那个泄露了融资计划书的“_old”目录。它提醒我：发布按钮按下去之前，先问问自己——这个东西如果被全世界看到，我能接受吗？如果答案是否定的，那就别让它上线。哪怕只是“临时”的。