![[Vibe Coder #8] 接受用户前的6项安全检查 封面图](/assets/images/posts/88a2c686-f9c2-4047-8809-30b6118aec87/launch-security-checklist-1.jpg)
应用已经完成并部署，现在只剩下把链接公开给全世界。系列最后一篇是公开前的最终检查：接受用户前必须确认的六项安全检查，以及从第1篇延续至今的整张地图总结。
开始前先澄清一个常见误解：“我的应用很小，也不出名，谁会攻击它？”正如第2篇所见，攻击者不是人，而是机器人。机器人不会挑选目标，而是撒网。 它们会自动扫描互联网上所有公开地址，寻找敞开的入口。应用小并不意味着安全，只意味着没有人替它把关。幸运的是，Vibe Coding 应用中容易被攻破的入口大多是固定的，下面这六个就是它们。
公开前检查清单6项
1. 是否有机密值泄露？ 这是第2篇的检查。确认 API 密钥没有暴露在前端或 GitHub 公开仓库中。给 AI 的指令：“找出这个项目中所有 API 密钥或机密值被发送到前端，或被提交到 Git 的情况。”
2. 后端是否执行权限检查？ 这是第1篇的原则。隐藏删除按钮只是装饰，任何人都可以发送请求。对于文章的删除、修改和查询，后端都必须确认“这个用户是否有资格执行此操作”。给 AI 的指令：“审计所有后端 API 是否检查登录状态和所有权，并列出遗漏的地方。”
3. 是否任何人都能进入 DB？ 仓库（DB）有自己的访问规则。以 Supabase 为例，就是 RLS（Row Level Security，行级安全）：简单来说，就是把“每一行数据谁能读写”的规则贴在仓库门上。如果它被关闭，就会打开一条不经过后端、直接闯入仓库的路径。在实际的 Vibe Coding 应用事故中，这是最常被指出的项目。给 AI 的指令：“检查我的 DB 表中是否有任何人都能读写的表，并告诉我如何锁定它们。”
4. 是否已准备好应对异常输入？ 用户会在输入框里填入任何内容：10万字的文章、奇怪的代码片段、空值。如果后端不验证输入的长度和格式，应用可能崩溃或被攻破。给 AI 的指令：“检查所有接收用户输入的地方是否都有长度限制和格式验证。”
5. 是否设置了费用安全装置？ 这是第7篇的5分钟设置：支出上限和预算提醒。从有用户开始，调用量就不再由我控制，因此公开前是最后的设置机会。
6. 是否有可以回退的地方？ 这是第3篇的存档点。提交并推送公开前的状态，并确认 DB 备份已开启。公开后第一次发生事故时，能否回到“正常运行的时点”将决定恢复速度。
如果逐项确认六项让你觉得麻烦，至少执行这个最后手段的提示词：“你是一名安全审计员。在公开这个项目之前，从机密值泄露、权限检查缺失、DB 访问规则和输入验证等角度，找出所有危险点，并按严重程度告诉我。”即使是创建时犯过错误的 AI，被要求进行审计后也能很好地找出问题。但不要直接相信 AI 的“现在已经安全了”，对照上面的清单逐项确认，这本身也是检查的一部分。
系列总结：一张地图
把八篇内容折叠成一张，就是这样。
- 第1篇 — 结构：应用由大厅（前端）、厨房（后端）和仓库（DB）组成。前端是公开空间，因此不要在其中放置机密。
- 第2篇 — API 密钥：密钥就是公司信用卡。它只能放在两个地方：
.env和部署面板。 - 第3篇 — Git：提交就是存档。每次运行正常时，以及每次重大修改前，都要存档。
- 第4篇 — 部署：部署就是搬到服务器。
.env不会随搬家行李一起装车，因此要单独登记到面板中。 - 第5篇 — 错误：错误消息就是自白书。连同上下文完整交给 AI。如果 AI 一直兜圈子，就改变方法。
- 第6篇 — 谜团：“明明什么都没改”的元凶是缓存、依赖、外部服务，以及昨天的自己。先从成本最低的检查开始，依次排查。
- 第7篇 — 费用：账单来自 Token、读写和流量。支出上限与提醒是5分钟就能设置的保险。
- 第8篇 — 公开前检查：锁好上面的六道门，再出发。
结语
这个系列没有教你编程，而是绘制了地图：我的应用由哪些部件组成，每个部件会在哪里造成什么事故，以及发生事故时该看哪里、该对 AI 说什么。Vibe Coding 的真正能力不是读代码，而是拿着这张地图向 AI 提出准确问题。
地图现在已经在你手中。做出好东西，让全世界看见。