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

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

Firebase services are reachable at predictable public addresses, so a scanner with no credentials can check each one the way an anonymous visitor would. FixVibe's Firebase check covers all three services independently:

• Firestore. FixVibe finds the project from the deployed app's own Firebase configuration and reports collections that anonymous visitors can read.
• Realtime Database. FixVibe reports a database whose data anonymous visitors can read — often the whole tree at once.
• Cloud Storage. FixVibe reports buckets that anonymous visitors can list. Listable storage is a finding even when individual downloads are denied, because it lets attackers find guessable filenames.

測試模式陷阱的真實面貌

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;
}

即時資料庫

{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } } } }。$uid 萬用字元擷取路徑區段以供比較。

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

雲端儲存

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;
    }
  }
}

Deploy rules via the Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage. Verify the new rules are in production by re-running the FixVibe scan — the open-rules finding should clear.

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

與 Firebase 內建工具的比較

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

常見問題

後續步驟

Run a free FixVibe scan against your production URL — the Firebase rules check runs on every plan and flags open rules across Firestore, Realtime Database, and Cloud Storage. For a deeper explainer on the allow read, write: if true pattern specifically, see Firebase allow read, write: if true explained. For the umbrella view across Supabase, Firebase, Clerk, and Auth0, read BaaS misconfiguration scanner.