// 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 秒內出結果 | 數小時:設定 spider、驗證、範圍 | 一天:整合到儲存庫 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。