AI 构建应用的修复指南
那些会毁掉氛围编程上线的安全漏洞——以及如何逐一堵上。通俗的分步操作，按真实风险排序。
- critical→
如何为 Lovable 应用添加行级安全（RLS）
Lovable 会配置一个 Supabase 数据库，但常把数据表留成对公开 anon 密钥可读。在你启用并写好行级安全策略之前，任何人都能读取你用户的数据。
- critical→
如何在 Supabase 上启用行级安全（RLS）
未启用 RLS 的 Supabase 表，任何持有 anon 密钥的人都能完全读取——而 anon 密钥会随前端一起发布。正确启用 RLS 是加固 Supabase 应用最重要的一步。
- critical→
如何修复暴露的 Supabase 密钥
分两种情况。anon 密钥本就该公开——如果只暴露了它，RLS 就是你的修复手段。但如果你的 service-role 密钥进入了客户端或公开仓库，你的整个数据库都已暴露，必须立即轮换。
- critical→
如何轮换暴露的 API 密钥
凡是进入前端或公开仓库的 API 密钥，都应视为已泄露。曾有创始人把 Stripe 私钥发布到前端，在他来得及轮换之前，175 名客户被扣款。要快速轮换，但顺序要对。
- medium→
如何为你的应用添加安全响应头
AI 生成的应用几乎总是缺少安全响应头，使你面临点击劫持、协议降级和内容注入攻击。添加它们既快速又高效。
- medium→
如何修复 CORS 错误（安全的做法）
修复 CORS 错误最快的「办法」——用通配符允许所有来源——同时也是一个安全漏洞：它让任何网站都能从受害者的浏览器调用你的 API。正确的修复只允许你信任的来源。
- critical→
如何保护你的环境变量和密钥
AI 构建的应用经常因为把密钥放进客户端环境变量、提交 .env 文件，或在打包文件中暴露密钥而泄露。任何进入浏览器的东西都是公开的——密钥只能存在于服务端。
- high→
Supabase RLS 最佳实践
启用 RLS 只完成了一半工作。即使 RLS「开着」，过于宽松或写错的策略仍会让数据暴露。下面这些实践能让 Supabase 行级安全真正保护你的数据。
- critical→
如何加固你的 Firebase 安全规则
Firebase 数据泄露的头号原因是规则被留在测试模式（'allow read, write: if true'），这会让你的整个数据库公开。安全的规则会把每一次读写都限制到经过认证、授权的用户。
想要的不只是修复，还要有人核实？
修复只是第一步。ClearedToShip 的复核会确认修复确实有效，并为你出具一份签署的、带保险的上线放行许可。加入抢先体验：