// docs / baas security / umbrella scanner
BaaS 配置错误扫描器:在用户之前找到公共数据路径
后端即服务提供商 — Supabase、Firebase、Clerk、Auth0、Appwrite、Convex — 都以相同的形态在安全性上失败:平台提供合理默认值,开发者 (或 AI 编码工具) 走捷径,在未认证攻击者和客户数据之间打开了一条公共路径。BaaS 配置错误扫描器是唯一一个像攻击者那样从外部探测该路径的工具。本文映射五个反复出现的配置错误类别,解释 FixVibe 总览 BaaS 扫描如何工作,比较四个主要提供商,并将 BaaS 感知扫描器与通用 DAST 工具进行对比。
为何 BaaS 配置错误有反复出现的形态
每个 BaaS 平台都遵循相同的架构:一个托管后端,加上一个从浏览器与它通信的薄客户端 SDK。面向浏览器的客户端需要某种凭据 — anon 密钥、可发布密钥、Firebase 项目 ID — 向后端标识自己。该凭据有意公开;架构的安全性取决于平台级访问控制 (RLS、规则、允许列表) 完成其工作。
AI 编码工具在这种架构之上构建,而没有内化平台控制层。它们正确地连接客户端 SDK,接受平台的默认宽松规则 (为教程友好性而存在),并发布。反复出现的形态是:公共凭据 + 宽松默认规则 + 缺失的覆盖 = 数据暴露。下面的五个配置错误类别都是这种形态的变种。
五个反复出现的配置错误类别
这些出现在每个 BaaS 提供商中。完整扫描对每个使用中的提供商覆盖所有五个:
类别 1:浏览器包中的错误密钥
浏览器发送秘密 / 管理员密钥 (Supabase service_role、Firebase Admin SDK 私钥、Clerk sk_*、Auth0 客户端机密) 而非公共 / anon 等效项。浏览器变成不受约束的管理员客户端。由 FixVibe 的包机密检查 覆盖。
类别 2:访问控制层被禁用或宽松
RLS 关闭、Firebase 规则是 if true、Auth0 回调列表是通配符。浏览器中的凭据是正确的 — 但本应约束它的平台级边界没有完成其工作。
类别 3:对敏感资源的匿名读取
可匿名读取的 Firestore 集合、可匿名列出的 Supabase 存储桶、可匿名访问的 Auth0 管理 API。扫描会问:「没有凭据,我能读取什么?」
类别 4:生产中的测试模式遗物
生产部署中的测试密钥 (pk_test_*、sb_test_*);从生产域名可达的 开发模式 Firebase 应用;比生产具有更弱设置的测试租户 Auth0 应用。扫描将运行时密钥与预期的生产前缀比较。
类别 5:缺失 webhook 签名验证
Clerk webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
FixVibe 总览 BaaS 扫描的工作原理
FixVibe 的 BaaS 阶段分三个阶段运行,每个阶段产生不同的发现:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- 阶段 3 — 跨提供商关联。扫描器交叉引用发现。泄漏的 Supabase 服务角色密钥加上缺失的 RLS 比任一发现单独更严重 — 报告会突出这一点。同一应用中的多个身份提供商 (Clerk + Auth0 + 自定义身份验证) 是一个标记为审查的结构性发现。
每个探测都是被动的:对每个资源最多一次匿名读取,记录响应形状但行内容从不分页或存储。写入和修改探测被验证的域名所有权所限制 — 它们永远不针对未验证的目标运行。
每个提供商扫描器找到什么
每个 BaaS 提供商都有不同的攻击面和不同的扫描策略。涵盖的内容:
- Supabase:表上缺失的 RLS、可匿名列出的存储桶、包中泄漏的
service_roleJWT 或sb_secret_*密钥、通过匿名 OpenAPI 列表暴露的模式。请参阅 Supabase RLS 扫描器 和 存储清单。 - Firebase:Firestore、Realtime Database 和 Cloud Storage 上的
if true规则;可匿名列出的 Storage 桶;缺失的 App Check 强制。请参阅 Firebase 规则扫描器 和 If-true 规则解释。 - Clerk:打包的
sk_*秘密密钥、生产中的pk_test_*、缺失的 webhook 签名验证、通配符允许的源。请参阅 Clerk 清单。 - Auth0:打包的客户端机密、启用的 Implicit 授权、通配符回调 / 注销 URL、SPA 上缺失的 PKCE。请参阅 Auth0 清单。
BaaS 扫描器与通用 DAST 和 SAST 工具的比较
BaaS 感知扫描器做其他工具不做的特定工作。比较如下:
| 维度 | FixVibe (BaaS 感知 DAST) | 通用 DAST (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| BaaS 覆盖 | Supabase、Firebase、Clerk、Auth0、Appwrite 的原生检查 | 通用网页抓取;无提供商特定探测 | 仅仓库的静态分析;无生产验证 |
| 设置时间 | URL → run → results usually in under a minute | 数小时:配置蜘蛛、身份验证、范围 | 一天:集成到仓库 CI |
| 它证明什么 | 带 HTTP 级证据的生产运行时暴露 | Web 应用漏洞 (XSS、SQLi);通过手动配置覆盖 BaaS | 可能部署也可能不部署的代码模式 |
| JavaScript 包检查 | Every shipped chunk, with provider-aware key detection | 有限 — 仅基于字符串的 grep | 是,但仅在仓库端,而非已部署 |
| 持续扫描 | 通过 API + MCP 每月 / 部署时 | 手动;自己配置计划 | 每次提交 (对代码有益,对运行时盲) |
| 单人 / 小团队价格 | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
常见问题
如果我的应用使用两个 BaaS 提供商 (例如 Supabase + Clerk),总览扫描有效吗?
是的 — 提供商指纹识别和每个提供商的探测是独立的。扫描器检测两者,运行两个检查套件,并报告跨提供商关联 (例如,来自 Clerk 的 Supabase JWT 模板,在缺失 RLS 的情况下将 email 作为声明发送)。
这与对我的应用运行 Burp Suite Pro 有何不同?
Burp 是一个通用 DAST 工作台。开箱即用,Burp 不知道 PostgREST、Firestore 或 Auth0 回调路径是什么 — 你必须手动配置范围、编写扩展并解释响应。FixVibe 自带内置 BaaS 探测和 BaaS 形状的证据格式化。Burp 在通用 Web 应用覆盖 (XSS、SQLi、业务逻辑) 上胜出;FixVibe 在 BaaS 特定发现上胜出。
App Check (Firebase) 或证明 (Apple / Google) 怎么样?
App Check 使机会主义外部扫描在每个探测上返回 403 — 这是恶意机器人的正确结果。来自未证明客户端的 FixVibe 扫描行为相同。如果你启用了 App Check 而 FixVibe 仍报告发现,这意味着你的规则也对已证明客户端开放,这才是真正的风险。App Check + 正确的规则是纵深防御模式。
扫描器能验证我的修复吗?
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
后续步骤
对你的生产 URL 运行免费的 FixVibe 扫描 — BaaS 阶段检查在每个套餐 (包括免费层) 上都提供。有关提供商特定的深度内容,本节中的各篇文章详细涵盖每个提供商:Supabase RLS、Supabase 服务密钥暴露、Supabase 存储、Firebase 规则、Firebase if-true、Clerk 和 Auth0。