AI-MVP 越权扫描器 —— 给 Lovable/Cursor 生成、已在收钱的 Supabase 应用做 IDOR/RLS 自动体检与一键修复

结论：做（付费者明确、切口小、事故驱动购买、大厂不做 Supabase 语义层，先用"扫描 + 人工兜底"验证再产品化）｜形态：SaaS（Web 报告 + GitHub PR 机器人，CLI 作分发钩子）

1. 产品定义与形态

输入一个 Supabase 项目（只读连接串 / schema dump）与代码仓库，输出三件事：①越权风险清单；②可点击的复现步骤；③一键修复 PR。核心检测项：IDOR（按 ID 直查不校验归属）、RLS 未启用或 using (true) 过宽策略、字段级越权（mass assignment 改 role/is_admin）、service_role key 泄漏到前端。形态以 SaaS 为主，CLI 用于在 GitHub Action 里做"上线前体检"，降低首次接入摩擦。

2. 目标客户画像

第一类，非技术/半技术创始人：原帖描述为 "They built it themselves in Lovable or Cursor, got it to paying users and now something's on fire and they want someone to look under the hood."（来源1）。特征是已有人付费、自己看不懂代码、出问题只能外购排查。第二类，做同类交付的小型外包/工作室（可白标）。第三类，正准备接企业客户或融资尽调的 AI 建站项目。月收入分布与团队规模待验证。

3. 付费者与付费证据

付费者就是创始人本人，预算来自"事故成本"而非合规预算，因此购买触发点是：数据泄漏被发现 / 客户投诉 / 尽调问卷 / 融资 DD。证据：来源1 明确指出这批项目"got to paying users and now something's on fire"，且创始人选择花钱请外部审计（"they want someone to look under the hood"）。原帖另一处举例："On one tutoring marketplace, changing the number at th…"（原帖摘录在此截断，完整句未见）。这说明越权在该站点是可被单一参数触发的真实缺陷，而非理论风险。待验证：客户单次愿意支付的具体金额区间与是否愿意转为订阅。

4. 时机判断

AI 编程工具把"能上线"的门槛降到非工程师可及，但授权模型（RLS/归属校验）属于工具不会替你思考的部分，形成结构性缺口。12 个样本中"几乎全部"中招（来源1），说明这不是个例而是系统性偏差。时机分 77。反向变量：Supabase 官方 lint 与 AI 工具自带安全提示若快速补齐，窗口收窄。

5. 市场前景

不引用任何市场规模数字。可判断的只有需求结构：每个 AI 生成、已获付费用户的 Supabase 项目都是一次潜在触达，但真正付钱的时刻大概率集中在"出事后"。因此更可能成立的模式是「免费扫描引流 + 一次性审计 + 持续监控订阅」三档组合，而非单纯订阅。TAM 与年付费转化率待验证。

6. 竞争格局

对手有四类：①通用 SAST（Snyk、Semgrep、GitHub Advanced Security）——覆盖广但不理解 Supabase 策略语义，报告面向工程师；②Supabase 官方安全提示（覆盖范围待验证）；③AI 工具自身的生成期护栏；④外包团队的人工审计（本次来源即是此类）。差异空间在于：Supabase 语义 + 非技术人话报告 + 一键 PR。竞争分 68，护城河来自规则库与案例积累，壁垒偏薄。

7. 90 天路线图

• D1–15：在 r/SaaS / r/lovable / r/Supabase 招募 10 个免费审计，全手工完成，沉淀"越权模式库"。
• D16–45：上线 CLI MVP，支持 Supabase schema + REST 路由静态扫描，先做 5 条高确定性规则（RLS 关闭、using(true)、按 ID 直查、字段可写 role、前端暴露 service key）。
• D46–70：做 GitHub App 自动 PR 修复 + 网页报告（复现步骤 + 人话解释）。
• D71–90：Product Hunt + Show HN 发布，落地页放免费"RLS 体检"，目标前 10 个付费。

8. 获客与运营

• 社区：发 r/SaaS、r/Supabase、r/lovable、r/nocode、r/indiehackers、r/webdev，方式为"我审计了 N 个 AI 建站项目，发现 X"的干货帖，不硬广。
• 其他渠道：Hacker News Show HN、Indie Hackers、Lovable 与 Supabase 官方 Discord 答疑区（免费帮看 RLS 策略）。
• SEO 关键词：supabase rls check、supabase rls policy tester、supabase security advisor、lovable app security、lovable supabase rls、bolt supabase security、is my lovable app secure、supabase idor。
• 白标：给做 AI 建站的外包工作室按项目计费，他们天然是分发方。

9. 地域需求分析

美加优先：SaaS 付费习惯强、r/SaaS 人群集中、美元定价阻力小。欧洲次之：GDPR 下的数据泄漏通报义务会提高"先体检"意愿（具体条款与执法力度待验证）。印度、东欧、东南亚：外包工作室密集、预算敏感，适合低价档或白标，而非直客订阅。以上排序为推断，均待验证。

10. 定价与收入模型

以下为假设，非市场数据：Free（1 项目、仅 RLS 检测）／$39 月 Solo（3 项目 + PR 修复）／$99 月 Team（10 项目 + 监控告警）／$299 一次性深度审计（人工复核 + 报告）／$1,500 起应急响应。收入推演假设：免费扫描 100 个项目 → 5% 转付费（待验证）≈ $195 MRR；叠加每月 2 单一次性审计 ≈ 总收入 $800/月量级。全部为假设，需用真实转化数据替换。

11. 风险与放弃条件

风险：①Supabase 官方把该检测做成免费功能（最大风险）；②需求多为一次性，订阅留存差；③要接触客户代码与密钥，信任与安全责任成本高；④AI 工具自带修复可能吞掉扫描层；⑤安全品牌需要信任背书，单人公司天然劣势。 放弃条件：手工 10 次审计中付费转化 < 2 单；或免费扫描→付费转化连续 60 天 < 1%；或 Supabase 官方推出等价免费能力；或获客成本持续高于首单毛利。

12. 总评分卡

建议：先做"服务"验证付费，再产品化。顺序是 手工审计 → CLI → SaaS 订阅，任何一步转化不达标即按第 11 节条件止损。