Creem 被封了！
整理版優先睇
Creem 封號事件：一個數據庫配置漏洞，令收入瞬間歸零
呢篇文章係獨立開發者孟健嘅親身經歷覆盤。佢嘅 AI 換臉工具 Kirkify 用 Supabase 做數據庫，因為冇開 RLS（Row-Level Security），成個數據庫俾人放咗上暗網論壇。支付平台 Creem 收到通知後，即使佢 6 小時內修復、寫咗萬字解釋，最終都被永久封號，餘額凍結 90 日。文章帶出兩個核心教訓：Supabase 嘅 RLS 唔係自動安全，獨立開發者太依賴第三方平台會好危險。整體結論係：要確保每個第三方服務都可以喺一星期內被替換。
背景方面，Kirkify 係用 Next.js、Supabase、Creem、Replicate 呢啲典型 indie stack，月收入穩定但全自動。出事原因係佢以為 Supabase 幫佢搞掂安全，實際上新表嘅 RLS 要手動開。Creem 作為 MoR，一見數據泄露就要切割，卡組織介入後無得商量。作者最後決定遷移到 Cloudflare D1 + Workers，自建認證系統，從架構上杜絕同類漏洞。
呢篇文對用 Supabase 或者任何第三方平台嘅獨立開發者係當頭棒喝：你嘅「護城河」唔係產品跑得快，而係出事後可以快速重建。
- Supabase 嘅 RLS 唔係默認安全，新表要手動開策略，否則 PostgREST 公開 API 會洩漏所有數據。
- 支付平台（Creem、Stripe）嘅合規審查冇得傾，一旦涉及數據泄露，佢哋會立刻切割商户以自保。
- 獨立開發者最大風險唔係冇用戶，而係過度依賴第三方平台，收入隨時歸零。
- 修復方案係將數據庫從 Supabase 遷到 Cloudflare D1（冇公開 API），認證系統自建，從架構消除漏洞。
- 核心能力要從「快速出產品」轉變為「任何平台炸咗之後 48 小時內恢復運轉」。
事件背景：Kirkify 同 Creem
孟健做咗個 AI 換臉工具 Kirkify，用 Replicate 跑模型，面向海外用戶收費。技術棧係典型獨立開發者組合：Next.js、Supabase、Creem、Cloudflare R2。產品跑咗幾個月，有穩定付費用戶，月收入雖然唔多，但全自動化運行。
Creem 係一個 MoR 支付平台，幫你搞税務、合規、退款。對獨立開發者嚟講，呢啲平台係救命稻草，因為一個人根本搞唔掂全球税務。但一切睇落好美好，直到 2 月 22 日。
一個數據庫配置，炸咗成條鏈路
有人喺 updap.com 開帖話 Kirkify.net Database Leaked Download。作者第一反應係唔信，因為用緊 Supabase。點知查完先知：10 張表大部份冇開 RLS。
Supabase 嘅 PostgreSQL 透過 PostgREST 暴露公開 REST API，如果冇 RLS 策略，個 API 任人查所有用戶數據。
- 洩漏咗：用戶郵箱、Google OAuth ID、Creem 客戶 ID、訂閲狀態、積分餘額、交易記錄、推薦碼
- 好消息係：冇洩漏信用卡資訊，因為支付全部行 Creem，數據庫冇卡號
6 小時緊急修復同全量遷移
發現問題後，作者同 AI 助手即刻執行緊急修補。第一步係幫所有表加 RLS 策略，例如只能讀寫自己嘅記錄、寫入只走後端。
光補 RLS 唔夠，Supabase 嘅架構本身就係風險——只要用 PostgREST，就要同 RLS 較勁。
- 1 數據庫：Supabase PostgreSQL → Cloudflare D1（SQLite，冇公開 API）
- 2 認證：Supabase Auth → 自建 JWT + HttpOnly Cookie
- 3 部署：Vercel → Cloudflare Pages + Workers
成個遷移用咗唔夠兩週，11 張表重新設計 schema，25 個 API 路由重寫，認證系統從零搭建。AI 助手幫咗大忙，大部分代碼係 AI 寫，作者負責架構決策同測試。
Creem 嘅反應：誠意換唔到原諒
作者寫咗一封非常詳細嘅回覆畀 Creem，逐表列出洩漏咗乜、冇洩漏乜、點樣修復、時間線。Creem 嘅 AI 客服要求提供安全配置證據，作者再補咗 RLS 策略表格同遷移進度。
Creem 最終回覆：卡組織同監管機構已介入，無法繼續支持，餘額凍結 90 天。你做啱曬所有嘢，但結果不變。
作者理解 Creem 嘅決定——佢作為 MoR，如果唔切割，下一個被審查嘅就係 Creem 自己。商業邏輯完全說得通，但理解還原諒，收入確實歸零。
三點教訓同未來方向
Supabase 嘅 RLS 係定時炸彈：PostgREST 暴露公開 API + RLS 默認唔開，等於俾所有獨立開發者埋雷。
第二，支付平台嘅合規審查冇談判權。你嘅修復速度同態度唔重要，佢哋要保護成個支付網絡嘅信譽。第三，獨立開發者最大風險唔係冇用戶，係平台依賴——每一個第三方都有權隨時終止服務。
Kirkify 唔會死。數據庫已遷到 Cloudflare D1，認證自建完畢，部署喺 Workers 上。支付方面會接入新渠道。心態上，從依賴平台轉向隨時可重建——呢個先係真正嘅護城河。
大家好，我係孟健。上個禮拜，我嘅 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：
第二步：啟動全面遷移
淨係補 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 嘅朋友。呢篇可能幫佢哋避開一個大坑。
有問題評論區傾，我每條都睇。
🚀 想同更多 AI 愛好者交流，一齊成長嗎？
📚 精選文章推薦
大家好，我是孟健。上週，我的 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：
第二步：啓動全量遷移
光補 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 的朋友。這篇可能幫他們避一個大坑。
有問題評論區聊，我每條都看。
🚀 想要與更多AI愛好者交流，共同成長嗎？
📚 精選文章推薦