Firebase 規則掃描器:找出開放的 Firestore、Realtime Database 與 Storage 規則

掃描器如何找到開放的 Firebase 規則

Firebase 服務暴露眾所周知、可預測的 URL 形狀。沒有憑證的掃描器可以探測每一個服務並觀察匿名讀取是否成功。FixVibe 的 baas.firebase-rules 檢查在每項 Firebase 服務上各自執行三個獨立探測:

• <strong>Firestore.</strong> The scanner extracts the project ID from the deployed app's bundle (it's in <code>firebase.initializeApp({ projectId: ... })</code>), then issues <code>GET https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents/[collection]:listDocuments</code> against common collection names. A <code>200 OK</code> with documents in the response means <code>allow read</code> is permissive.
• Realtime Database。掃描器探測 https://[project-id]-default-rtdb.firebaseio.com/.json。如果根節點可匿名讀取,回應就是整個資料庫樹的 JSON。較保守的測試查詢 .json?shallow=true,它只傳回頂層鍵 — 無論哪種情況都是一項發現。
• Cloud Storage。掃描器查詢 https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o。如果回應在無驗證的情況下列出檔名,則該儲存桶可匿名列出。即使個別檔案下載被拒絕,可列出的儲存仍是一項發現 — 攻擊者會列舉儲存桶以找出可猜測的檔名。

測試模式陷阱的真實面貌

Firebase 的快速入門文件包含網路上最常被複製的規則區塊之一:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Firebase 過去會為這些規則加上自動 30 天到期。情況已經改變:現今,除非開發者替換,否則規則會永久存續。AI 編碼工具 — 在多年含測試模式區塊的文件上訓練 — 經常逐字發出它,並告訴開發者「這就是你的安全規則」。它不是。

出現在生產中但同樣寬鬆的其他變體:

// future-date variant — equivalent to "if true"
allow read, write: if request.time < timestamp.date(2099, 1, 1);

// authenticated-user variant — any signed-in user reads and writes anything
allow read: if true;
allow write: if request.auth != null;

// any-auth variant — any signed-in user owns every document
allow read, write: if request.auth != null;

• 未來時間戳變體:一個允許一切直到遙遠未來日期的規則。實際上永不過期 (見上方醒目提示區塊)。
• allow read: if true; allow write: if request.auth != null; — 公開讀取,任何已驗證使用者可寫入。
• allow read, write: if request.auth != null; — 任何登入的使用者都能讀或寫任何文件,包括其他使用者的資料。

掃描器發現開放規則時該怎麼做

開放的 Firebase 規則是執行時的緊急事件。三項服務上的修復形狀相同:將每條規則限定到 request.auth.uid,並比對明確的擁有者欄位。每項服務都有自己的規則語法:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }。路徑區段繫結 {userId} 會成為使用者唯一能接觸的文件。

match /users/{userId} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Realtime Database

<code>{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }</code>. The <code>$uid</code> wildcard captures the path segment for comparison.

{
  "rules": {
    "users": {
      "$uid": {
        ".read":  "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage { match /b/{bucket}/o { match /users/{userId}/{allPaths=**} { allow read, write: if request.auth.uid == userId; } } }。慣例:將檔案存放於 users/[uid]/[filename],讓路徑強制所有權。

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

透過 Firebase CLI 部署規則:firebase deploy --only firestore:rules、firebase deploy --only database、firebase deploy --only storage。透過重新執行 FixVibe 掃描來驗證新規則已在生產中生效 — baas.firebase-rules 發現應該會被清除。

firebase deploy --only firestore:rules
firebase deploy --only database
firebase deploy --only storage

與 Firebase 內建工具的比較

Firebase 主控台向你顯示目前的規則,但不會根據執行時行為對其稽核。Firebase Rules 模擬器讓你以合成請求測試規則邏輯 — 有用但屬於本機。這兩個工具都不會告訴你生產規則實際對網際網路上的匿名攻擊者傳回什麼。像 FixVibe (或手動設定的 Burp Suite) 這樣的外部掃描器,是唯一從攻擊者相同角度進行探測的工具。Google 自家的 App Check 可緩解濫用,但無法取代正確限定範圍的規則。

常見問題

後續步驟

對你的生產 URL 執行免費的 FixVibe 掃描 — baas.firebase-rules 檢查在每個方案上都提供,並會標記 Firestore、Realtime Database 與 Cloud Storage 中的開放規則。關於 allow read, write: if true 樣式的深入說明,請參閱 Firebase allow read, write: if true 解析。關於跨 Supabase、Firebase、Clerk 與 Auth0 的總覽,請閱讀 BaaS 設定錯誤掃描器。