用途：面向 Firebase（Firestore、Storage、Auth）与 Supabase（REST API、Storage、Auth）后端的配置错误探测，属于授权安全测试中的侦察与验证环节。
主要能力：从 JS 打包文件或源码泄露中提取 Firebase 配置（apiKey、projectId）及 Supabase URL 与 anon key；枚举 Firestore 集合与文档、Storage 对象；测试 Firebase Auth 注册并生成 ID Token；枚举 Supabase 表、执行 SELECT/INSERT/UPDATE/DELETE 测试以验证 RLS 缺失；测试 Supabase Auth 注册与跨组织访问。
使用方式：需具备 curl、python3、jq；Firebase 服务账号密钥利用需 python3 的 google-auth。核心命令保留原样，如：curl --max-time 30 --connect-timeout 10 -sk "https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases/(default)/documents/"，以及 Supabase 查询示例 curl -sk "https://PROJECT.supabase.co/rest/v1/users" -H "apikey: ANON_KEY" -H "Authorization: Bearer ANON_KEY"。流程分八阶段：从 JS 中提取配置、Firestore 枚举、集合与文档访问、Auth 注册与令牌生成、Storage 枚举、Supabase REST 枚举、CRUD 与 RLS 绕过测试、Supabase Auth 注册。
适用场景：目标为使用 BaaS 的现代 SPA（React、Vue、Angular），在 js-secrets-extraction 或 source-leak-hunt 发现相关标识后使用。
限制：anon key 本身设计为公开，漏洞在于 RLS 缺失而非密钥暴露；Firestore 规则可能只允许读不允许写，需分别测试；不同表 RLS 可能不一致；Auth 注册可能要求邮箱验证；Firestore REST 存在速率限制，大规模提取应间隔 0.5–1 秒；JS 中的密钥可能被截断，测试返回“API key not valid”时应提取周围上下文以还原完整密钥；Firebase 项目可能未部署任何资源，需分别检查各端点。验证要求：Firestore 必须在无认证下枚举成功，Supabase REST 仅用 anon key 返回 HTTP 200 与数据，CRUD 至少一次写操作成功，Auth 注册返回令牌，Storage 无认证可列出对象。资料未提供收费、价格与具体平台效果信息。