Supabase RLS 未配置导致数据泄露，我的 SaaS 被支付平台封号冻结 90 天

开发者孟健的 SaaS 产品 Kirkify（AI 换脸工具）因 Supabase 数据库配置漏洞导致用户数据泄露，被支付平台 Creem 永久封号，账户余额冻结 90 天。本文复盘事件经过和核心教训，帮助其他独立开发者避坑。

事件经过

Kirkify 的技术栈：Next.js + Supabase + Creem（支付）+ Replicate（AI）+ Cloudflare R2。产品有稳定付费用户，月收入虽不多但全自动化运行。

2026 年 2 月 22 日，有人发现 Kirkify 的数据库暴露在公开论坛上。原因是 Supabase 的 PostgreSQL 数据库通过 PostgREST 暴露了公开 REST API，但大部分表没有配置 RLS（Row-Level Security）。

泄露的数据：用户邮箱、名字、Google OAuth ID、Creem 客户 ID、订阅状态、积分余额、交易记录。好消息是信用卡信息没有泄露（支付全部走 Creem）。

6 小时紧急修复

• 给所有 10 张表加上了 RLS 策略
• 决定彻底迁移：Supabase PostgreSQL → Cloudflare D1，Supabase Auth → 自建 JWT，Vercel → Cloudflare Pages + Workers
• 全量迁移用了不到两周，11 张表重新设计 schema，25 个 API 路由全部重写

诚意满满的回复

孟健给 Creem 写了一封非常详细的回复：逐表列出泄露字段、明确说明没有信用卡信息、贴了完整的 RLS 补丁和迁移方案。

但 Creem 的最终回复是：卡组织和监管机构已介入审查，无法继续提供服务，余额冻结 90 天。

三个核心教训

教训一：Supabase 的 RLS 是定时炸弹

Supabase 通过 PostgREST 暴露公开 REST API，但 RLS 默认不开启，每张表需要手动配置。如果你用了 Supabase 但没主动检查每张表的 RLS 策略，你的数据库可能也是裸奔状态。

常见的错误用法：前端直接用 Supabase 的 anon key + PostgREST API 查表，RLS 没开 = 任何人都能查所有数据。

正确的做法是：环境变量里只保留数据库连接字符串，所有查询在 server function 中完成，anon key 和 service_role key 不出现前端项目中。

教训二：支付平台的合规审查没有谈判权

Creem 的回复很明确：这不是 bug 修了就完事的，是合规问题。卡组织（Visa、Mastercard）看到数据泄露报告后会介入。支付平台为了自保，切割商户是唯一选择。

修复速度不重要，态度不重要。在支付平台眼里你不是"勤奋的独立开发者"，你只是一个风险节点。这个道理放在 Stripe、PayPal、LemonSqueezy 上都一样。

教训三：独立开发者最大的风险是平台依赖

数据库可以迁，代码可以重写，但支付渠道被切断，收入就归零了。

你依赖的每一个第三方平台都有权在任何时候终止你的服务。Supabase 可以封你，Stripe 可以冻你，Vercel 可以停你——你以为在创业，其实在别人的平台上租了个摊位。

总结

Kirkify 不会死——数据库已迁到 Cloudflare D1，认证系统自建，但 90 天资金冻结是实打实的代价。

核心能力不是"快速出产品"，而是在任何平台炸了之后 48 小时内恢复运转。不是不用第三方，是要确保每个第三方都可以在一周内被替换掉。

转自孟健在知乎的文章，经提炼总结后发布。