// 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 webhook、Stripe webhook、Supabase webhook 都签名其载荷。不验证签名的处理程序对任何猜中 URL 的攻击者来说就是数据库写入原语。通过响应形状检测 — 获得 200 的未签名请求意味着验证被跳过。
FixVibe 总览 BaaS 扫描的工作原理
FixVibe 的 BaaS 阶段分三个阶段运行,每个阶段产生不同的发现:
- <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
- 阶段 2 — 提供商特定探测。对每个检测到的提供商,扫描器运行提供商特定的检查:
baas.supabase-rls探测 PostgREST;baas.firebase-rules探测 Firestore + RTDB + Storage;baas.clerk-auth0验证打包密钥的前缀;包机密检查验证没有服务级凭据泄漏。每个探测独立运行 — Supabase 发现不会阻塞 Firebase 扫描。 - 阶段 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 → 运行 → 60 秒内出结果 | 数小时:配置蜘蛛、身份验证、范围 | 一天:集成到仓库 CI |
| 它证明什么 | 带 HTTP 级证据的生产运行时暴露 | Web 应用漏洞 (XSS、SQLi);通过手动配置覆盖 BaaS | 可能部署也可能不部署的代码模式 |
| JavaScript 包检查 | 解码 JWT、匹配机密前缀、遍历块 | 有限 — 仅基于字符串的 grep | 是,但仅在仓库端,而非已部署 |
| 持续扫描 | 通过 API + MCP 每月 / 部署时 | 手动;自己配置计划 | 每次提交 (对代码有益,对运行时盲) |
| 单人 / 小团队价格 | 免费层;付费从 $19/月起 | Burp Pro $499/年;ZAP 免费但误报多 | Snyk 免费 / Semgrep 免费;付费层从 $25/开发者起 |
诚实的范围:此扫描器不替代的内容
BaaS 感知 DAST 扫描器是一个聚焦的工具,而不是完整的安全程序。它不:
- 替代 SAST 或 SCA。静态分析发现 DAST 扫描器无法发现的依赖 CVE (Snyk、Semgrep) 和代码级漏洞 (SonarQube)。两者都运行。
- 替代手动渗透测试。人工渗透测试人员能发现任何扫描器都无法发现的业务逻辑缺陷、授权边缘情况和链式漏洞。在大型发布或合规审计前雇用渗透测试人员。
- 审计你的代码或仓库以查找 git 历史中的机密。包机密检查涵盖当前部署的内容,而非历史上提交的内容。使用
git-secrets或gitleaks进行仓库卫生。 - 涵盖非 BaaS 后端服务。如果你的应用使用自定义后端 (Express、Rails、Django、FastAPI),FixVibe 扫描其 HTTP 表面,但不探测其后面的数据库或基础设施。那是通用 DAST + SAST 的领域。
常见问题
如果我的应用使用两个 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 + 正确的规则是纵深防御模式。
扫描器能验证我的修复吗?
是的 — 应用修复后重新运行。检查 ID (例如 baas.supabase-rls) 在各次运行间保持稳定,因此你可以对发现做差异比较:在运行 1 中 open 而在运行 2 中不存在的发现是修复已生效的证据。
后续步骤
对你的生产 URL 运行免费的 FixVibe 扫描 — BaaS 阶段检查在每个套餐 (包括免费层) 上都提供。有关提供商特定的深度内容,本节中的各篇文章详细涵盖每个提供商:Supabase RLS、Supabase 服务密钥暴露、Supabase 存储、Firebase 规则、Firebase if-true、Clerk 和 Auth0。