AI 帮你三天做了个 App，也帮你三天泄了全库

150 万个 API token，35000 个邮箱地址。任何人都能读，而且能写。

据云安全厂商 Wiz 在 2026 年 1 月披露的一起事故，一款社区产品的数据库处于完全裸奔的状态，根因只有两条：把匿名密钥硬编码在了前端，以及没有开启行级安全。

这两条都不是高深的攻击手法。它们是两个默认设置没有被改过。

先说一个几乎所有人都犯过的判断错误，再说处方。

一、"能跑起来"和"能上线"，是两件完全不同的事

三天做出一个能用的东西，这件事本身没有问题。演示的时候，注册能注册，登录能登录，数据能存能取，页面也挺好看。

问题出在这场演示证明了什么。它证明的是功能在，不是边界在。

上线之前真正要问的问题，和演示时问的那个问题，方向是相反的：

• →演示问的是：我能不能做到我该做的事？
• →上线要问的是：别人能不能做到他不该做的事？

这两个问题在演示现场长得一模一样，因为演示的时候只有你一个人在用，而你只会走自己设计好的那条路。你不会去猜别的账号的编号，不会去看浏览器里到底发出去了什么，更不会去试着改一条不属于自己的记录。

还有一个更隐蔽的错觉，来自"它是我自己做的"这个念头。自己做的东西，你会默认它很小、很不起眼、没人会盯上。但扫描是自动的，不挑大小——公网上的扫描不关心你有多少用户，只关心哪个端口开着、哪个接口不要凭证。它找到你，跟你重不重要没有关系。

所以判断标准得换一个：只要它在公网上能打开，它就已经进入了被检查的范围，跟它上线几天、有几个用户、是不是"内部先用用"都无关。

二、两个事故，一个根因

事故一：那 150 万个 token 是怎么漏出去的。

据 Wiz 在 2026 年 1 月的披露，根因是两条叠在一起：

第一条，匿名密钥被硬编码在前端。前端是什么？是发给每一个访客的那份代码。写进前端的东西，等于公开张贴。这里没有"藏得深一点"的说法——浏览器能拿到，就是所有人都能拿到。

第二条，没有开启行级安全。行级安全管的是"拿到这把钥匙的人，能看到哪些行"。没开，意味着拿到钥匙就能看全表。

这两条单独看，任何一条都不至于致命：密钥漏了但权限锁得住，损失有限；权限没锁但密钥没漏，也还有一层。凑到一起，就是 150 万个 token 加 35000 个邮箱可读可写。

事故二：平台自己也会栽。

据某 AI 建站平台在 2026 年 4 月发布的官方事故说明，在约 11 周的时间里，平台上 public 项目的源码与聊天记录可以被任意一个登录用户读取。

这件事里有两个点比数字本身更值得记住。

一是出问题的是平台方，不是某个用户手滑。也就是说，这类错误不是"新手才会犯"。

二是11 周。这类问题不会自己报警，不会让服务变慢，不会在监控面板上亮红灯。它安安静静地存在着，直到有人偶然发现。你不能靠"没出事"来推断"没问题"——在被发现之前，出事和没出事看起来完全一样。

再放一个对照。 据中央广播电视总台 2026 年 1 月 8 日的报道，国家安全部通报过这样的真实案例：开源 AI 工具默认开启公网访问且未设密码，敏感资料被境外 IP 下载。

三件事，根因是同一句话：默认配置是给开发方便用的，不是给上线用的。

默认值的设计目标，是让你尽快跑起来——少一步配置，就少一个卡住的人。这个目标和"安全地对陌生人开门"从来不是同一个目标，也从来没有被同一个开关同时满足过。工具越好用，默认值就越宽松，因为它要把你能遇到的障碍全部提前挪开。它挪开的那些障碍，有一部分本来就是门。

三、上线前必做的三件事

三件，不多。顺序不能反，每件都带一个约束。

第 1 件：密钥一律不进前端。

判断方法只有一句：凡是浏览器能拿到的，就当成已经公开。 不要评估"藏得深不深"、"会不会有人去看"、"打包之后是不是看不出来"——这些评估全都是错的方向，因为它们讨论的是"发现的难度"，而正确的假设是"已经被发现了"。

所有需要保密的密钥只放在服务端。约束是：已经进过前端的密钥，不能只是删掉，必须作废重发。 删掉只解决了以后，解决不了之前——那份代码已经发给过每一个访客了，你收不回来。这一条最容易被跳过，因为作废重发要改好几个地方，而删掉只要一分钟。

第 2 件：数据库默认拒绝，再逐条开权限。

顺序是这一条的全部内容：先把默认设成全部拒绝读写，然后一张表一张表地往回开。

每开一条权限，都要写清楚三件事：谁、能看哪些行、能改哪些行。"能看哪些行"是核心——绝大多数事故不是"外人看到了内部数据"，而是"用户 A 看到了用户 B 的数据"。这两种在权限规则里的写法完全不同，前者靠登录挡，后者只能靠行级规则挡。

约束是：不许用"先全开、以后再补规则"的顺序。 这个顺序在时间上说得通，在现实里从没被补完过——因为全开的时候一切正常，没有任何东西会提醒你还欠着一份规则。

第 3 件：上线前，找一个没参与开发的人，拿普通账号试着读别人的数据。

这一件最便宜，也最容易被省掉。四个约束：

• →必须是没参与开发的人。 参与的人只会走自己设计的那条路，这是人的问题不是态度问题。
• →必须用普通账号，不用管理员账号。管理员看得到不算问题，普通账号看得到才是问题。
• →必须给一个明确目标：把另一个账号的某一条数据读出来，或者改掉。目标含糊，他就只会点点首页说"挺好的"。
• →把他做过的每一步记下来，连同日期一起存档。这份记录以后是你唯一能拿出来的东西。

半天就够。找不到这样一个人，就把上线推迟到找得到为止——这不是拖延，这是这三件事里唯一一件能发现你"没想到的那种情况"的。

四、上限：第一版不接真实客户数据，用假数据跑满两周

先给上限，再给顺序。

上限是：第一版不接入任何真实客户数据。 用假数据，跑满两周。

假数据有要求，别用三条测试记录糊弄。条数、字段、长度都按真实量级造：真实会有一万条，就造一万条；真实会有手机号和地址两个字段，假数据里也得有这两个字段。量级差太远，很多问题在两周里根本不会出现——查询慢、翻页越界、导出超时，这些都只在有量的时候才露头。

两周里只盯一件事：有没有出现"这条数据不该被这个账号看到"的情况。 别同时盯性能，别同时盯体验，别同时加功能。两周内加了功能，这两周就得重来——因为新功能几乎总是伴随着一条新开的权限。

两周之后要导入真实数据，导入之前把第 3 件事再做一遍。这是我最想强调的一条：权限规则在加功能的过程中最容易被改松，而改松它的那个人当时的动机通常都很正当——"先让它能用，回头再收紧"。回头这一步，跟第 2 件里说的"以后再补规则"是同一个毛病。

接下来是代价，说清楚再开工。

第一，这三件事会让你的上线慢三到五天。 拆开看：第 3 件半天；第 1 件如果密钥已经进过前端，重发要小半天；最费时间的是第 2 件，把权限一条条写清楚、一张表一张表地过，通常要两到三天。这三到五天是实打实的延期，没有捷径，也不能并行——第 3 件必须在前两件做完之后做，否则测不出什么。

第二，把这三到五天和一次事故摆在一起比。 慢三到五天，你事先知道要花多少：几个人天，一次延期。泄一次，你事先不知道要花多少——通知、作废全部密钥、排查哪些数据被改过，以及最贵的那一项：你没有办法证明数据没被改过。 前一笔支出是有上限的，后一笔没有上限，这是它们唯一的区别，也是唯一重要的区别。

第三，什么时候可以少做一件。 如果这东西只在内网用、不上公网、里面不存任何别人的信息，那第 3 件可以省，第 1、2 件仍然要做。这三件事只有在"有陌生人能访问它，且它里面存了别人的信息"这两个条件同时成立时，才全都是必须的；纯内部的小工具，把它关在内网里，比给它写一整套权限规则便宜得多。

第四，别把这句话反过来用。 "我们还没正式上线，所以先不管"——那个 11 周的事故已经说明了，一个问题开始存在的时间，和它被发现的时间，中间可以隔很久。没上线不等于没人能打开，只等于还没有人告诉你有人打开过。

如果你接下来打算把这套东西搬到自己的机器上，先看《私有化部署到底多少钱：一个 17.38 万元的真实成交价》那一篇，把账算清楚再搬。搬家不会让上面这三件事变得不必要，只会让它们变成你自己的活儿。