大家好，我是孟健。上周，我的 SaaS 产品 Kirkify 被支付平台 Creem 永久封号，账户余额冻结 90 天。
起因不是欺诈，不是洗钱，是我自己的数据库配置漏洞------被人发到了暗网论坛上。
这件事从发现到处理只用了 6 小时，我甚至做了全套迁移、写了万字回复。但结果是：Creem 说，不好意思，卡组织和监管机构已经介入了，我们无法继续为你服务。
今天完整复盘这件事，因为我踩的坑，你们大概率也会踩。
01 先说背景：Kirkify 是什么
Kirkify 是我做的一个 AI 换脸工具，用 Replicate 跑模型，面向海外用户收费。
技术栈很典型的独立开发者组合：
- 前端：Next.js
- 数据库：Supabase（PostgreSQL）
- 支付：Creem（Merchant of Record，类似 Stripe 但帮你处理税务和合规）
- AI：Replicate（按次调用，不用自己部署 GPU）
- CDN：Cloudflare R2
产品跑了几个月，有稳定付费用户，每天都有订单进来。月收入虽然不多，但全自动化运行，属于标准的被动收入。
说一下 Creem。它是一个面向独立开发者的 MoR（Merchant of Record）支付平台，帮你处理全球税务、合规、退款这些脏活。简单说，你只管卖产品，税怎么交、发票怎么开、不同国家的 VAT 怎么算，全是 Creem 的事。
对独立开发者来说，这类平台就是救命稻草。因为你一个人根本搞不定全球税务合规。
一切看起来都很好------直到 2 月 22 日。
02 一个数据库配置，炸了整条链路
那天我收到消息：有人在 updap.com（一个数据泄露论坛）发了一个帖子：Kirkify.net Database Leaked Download。
我的第一反应是不信。我用的是 Supabase，它不是有 RLS（Row-Level Security）吗？
查了之后我麻了：10 张表里，大部分根本没开 RLS。
Supabase 有个你必须知道的设计：它的 PostgreSQL 数据库会通过 PostgREST 暴露一个公开的 REST API。如果你没有给表配置 RLS 策略，那这个 API 就能直接查到所有用户的数据。
泄露的内容包括：
- 用户邮箱、名字、Google OAuth ID
- Creem 的客户 ID、订阅 ID、订阅状态
- 积分余额、交易记录
- 推荐码、邀请关系
唯一的好消息是：没有泄露任何信用卡信息。因为支付全部走 Creem，卡号、CVV 这些我数据库里压根就没有。
但这不重要。Creem 看到的是：你的数据库被人挂到暗网上了。
📍 这里有个认知误区：很多独立开发者觉得"我用了 Supabase 就安全了"。不是的。Supabase 给了你枪，但子弹要你自己上。RLS 不是默认开启的，你建的每张表都需要手动配置。
03 6 小时紧急修复
发现问题后，我和 AI 助手立刻执行了紧急修补：
第一步：RLS 全量补丁（当天完成）
给所有 10 张表加上了 Row-Level Security：
| 表 | 策略 |
|---|---|
| billing_customers | 只能读写自己的记录 |
| billing_subscriptions | 只能读写自己的记录 |
| credit_balances | 只读自己的，写入只走后端 |
| credit_transactions | 只读自己的，写入只走后端 |
| billing_events | 完全封死，前端零访问 |
| waitlist | 只能插入，不能读 |
| referral_codes | 只能访问自己的 |
| video_predictions | 只能看自己的 |
第二步：启动全量迁移
光补 RLS 不够。Supabase 的架构天然就有这个风险------只要用 PostgREST，就得和 RLS 较劲。
所以我决定彻底迁走：
- 数据库：Supabase PostgreSQL → Cloudflare D1（SQLite，没有公开 API）
- 认证：Supabase Auth → 自建 JWT + HttpOnly Cookie
- 部署：Vercel → Cloudflare Pages + Workers
整个迁移用了不到两周，11 张表重新设计 schema，25 个 API 路由全部重写，认证系统从零搭建。
说实话，这个迁移本身就是一篇可以单独写的文章。AI 助手在里面帮了大忙------从生成 D1 schema 到重写数据访问层，大部分代码是 AI 写的，我负责架构决策和测试。两周前这还不可能，现在是常规操作。
迁移前 vs 迁移后：
- 迁移前：数据库有公开 REST API → 一个配置失误就全裸
- 迁移后：D1 没有公开 API → 这类漏洞从架构上不可能发生
04 万字回复，诚意拉满
Creem 发来调查邮件后，我写了一封非常详细的回复：
- 泄露了什么：逐表列出所有可能暴露的字段
- 没泄露什么：明确说明没有任何信用卡信息
- 怎么修的：贴了完整的 RLS 补丁和迁移方案
- 时间线：从发现到修复只用了几个小时
Creem 的 AI 客服 Creemie 回复说：请提供你的 Store ID 和安全配置证据。
我又写了第二封，附上了详细的 RLS 策略表格和迁移进度。
然后等来的回复是：
"虽然我们理解可能会出现配置错误，也认可贵团队采取的迅速行动，但遗憾的是，我们无法继续为贵公司在 Creem 平台上的业务提供支持。"
"鉴于事件的性质，卡组织和监管机构已介入审查。"
"您的余额已被冻结 90 天。"
你做对了所有事情，但结果不变。
05 这件事教会我的三件事
第一：Supabase 的 RLS 是个定时炸弹
不是 Supabase 不好。它确实降低了后端开发的门槛。
但 PostgREST 暴露公开 API + RLS 默认不开 = 给所有独立开发者埋了一颗雷。
你现在就该去检查你的 Supabase 项目：每张表是不是都开了 RLS？策略是不是正确的？
如果你回答不了这两个问题，你可能和两个月前的我一样。
第二：支付平台的合规审查，你没有谈判权
Creem 的回复很客气，但意思很明确：这不是 bug 修了就完事的，是合规问题。
卡组织（Visa、Mastercard）看到数据泄露报告后会介入。一旦介入，支付平台为了自保，大概率会选择切割。
你的修复速度不重要。你的态度不重要。他们要保护的是整个支付网络的信誉，不是你一个商户。
这个道理放在 Stripe、PayPal、LemonSqueezy 上都一样。你在它们眼里不是"勤奋的独立开发者"，你只是一个风险节点。
我甚至有点理解 Creem 的决定。它作为 MoR，Visa/Mastercard 查到它的商户出了数据泄露，如果不切割，下一个被审查的就是 Creem 自己。商业逻辑上完全说得通。
但理解归理解，你的收入确实归零了。
第三：独立开发者最大的风险不是没用户，是平台依赖
数据库可以迁。代码可以重写。但支付渠道被切断，你的收入就归零了。
而且这不是你能控制的。你依赖的每一个第三方平台，都有权在任何时候、以任何理由终止你的服务。
- Supabase 可以封你
- Creem/Stripe 可以冻你
- Vercel 可以停你
- 甚至 Google OAuth 可以限你
你以为你在创业，其实你在别人的平台上租了个摊位。
06 接下来怎么办
Kirkify 不会死。
数据库已经迁到 Cloudflare D1，认证系统自建完毕，部署跑在 Cloudflare Workers 上。从架构上说，现在比之前安全了 10 倍。
支付方面，我会接入新的支付渠道。90 天冻结期之后，Creem 的余额会释放。
但更重要的是心态上的转变：
以前我觉得独立开发者的核心能力是"快速出产品"。
现在我觉得，核心能力是在任何平台炸了之后，48小时内恢复运转。
不是不用第三方，是要确保每个第三方都可以在一周内被替换掉。
写到这里，想到一个事：
两个月前我还在公众号写"AI 编程如何提效"，两个月后我在用 AI 助手紧急修数据库漏洞、起草合规回复、执行基础设施迁移。
这大概就是独立开发者的日常------没有什么是稳定的，能随时重建的才是真正的护城河。
觉得有用？转给你身边用 Supabase 的朋友。这篇可能帮他们避一个大坑。
有问题评论区聊，我每条都看。
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏