Vibe Coding 安全清单：AI 生成的应用上线前要做的 12 项检查

AI 编程工具很擅长把应用做出来，却不太在意别人能不能也「用」你的应用。对 Lovable、Bolt 等工具生成的应用做公开扫描，反复发现的总是那几类问题，而且几乎都能从应用外部、不登录就看到。

最常见的三类错误

1. 数据库没开行级安全（RLS）。 Supabase 和 Firebase 本来就会把一个公开密钥交给前端。这只有在每张表都配置了「谁能读写哪些行」的规则时才安全。一位研究者扫描了 1,645 个上线的 Lovable 项目，发现其中 170 多个的行级安全配置有误（编号 CVE-2025-48757）。RLS 一关，公开密钥就能读出整张表。

2. secret 密钥被打包进浏览器。 工具接入 Stripe、OpenAI 或 Supabase 管理接口时，最快跑通的写法往往是把 secret key 写进前端代码。JavaScript 包里的任何东西都是公开的。一次针对 Bolt 托管应用的扫描发现，大约 7% 的应用硬编码了密钥。

3. 服务端缺少基本防护。 没有安全响应头，自托管部署时 .env 或 .git 目录可以访问，错误页面过于详细，接口直接信任浏览器传来的用户 ID。

检查清单

分享链接之前，逐项过一遍。

密钥与 secret

1. 在构建产物（而不只是源代码）里搜索 sk_live_、sk-、service_role、sb_secret_、AKIA 和 -----BEGIN。免费扫描器会对你的首页及其脚本做这项检查。
2. 前端只放可公开的密钥：Stripe pk_、Supabase anon / publishable key、Firebase Web 配置。其他的一律放在服务端环境变量里。
3. 如果某个 secret 曾经出现在前端代码或公开仓库里，立即轮换。从代码里删掉并不能让它「取消泄露」。

数据库规则

4. Supabase：为每一张表开启 RLS 并编写策略，然后在后台运行 Security Advisor。Firebase：Firestore 或 Storage 规则里不能有 allow read, write: if true。
5. 以陌生人身份测试：用无痕窗口打开应用，只用 anon key 调用你的 API 或 Supabase REST 接口，尝试读取其他用户的数据。

服务端检查

6. 每个 API 路由都在服务端校验会话。永远不要信任浏览器传来的 userId、role 或 price。
7. 对登录、注册、重置密码以及任何会花钱的接口（AI 调用、邮件、短信）做限流。
8. 校验上传文件的类型和大小，存放在网站根目录之外或对象存储中。

部署

9. 全站 HTTPS，HTTP 重定向到 HTTPS，并开启 HSTS。
10. 安全响应头：Content-Security-Policy、frame-ancestors、X-Content-Type-Options: nosniff、Referrer-Policy。
11. .env、.git、source map 和调试页面都不能从公网访问。
12. 运行时使用受支持的版本：打过 2026 年 10 月安全更新的 Node.js 22、24 或 26，或者 PHP 8.2.35+ / 8.3.36+ / 8.4.27+ / 8.5.12+。

扫描器能告诉你什么，不能告诉你什么

外部扫描几秒就能查出第 1、9、10、11 项，看到 Supabase 时还会提醒你检查第 4 项。它看不到你的 RLS 策略和 API 授权逻辑，因为这些只有在有人主动尝试突破时才会暴露。对于这些，用第二个账号测试，或者请没看过代码的人来试试。

现在就扫描你的应用，修复发现的问题，然后再扫一遍。如果报告太长、你没时间处理，集中修复服务可以一次性处理密钥、响应头和服务器配置。