Firebase rules scanner: ค้นหา Firestore, Realtime Database และ Storage rule ที่เปิดอยู่

สแกนเนอร์พบ Firebase rule ที่เปิดอยู่อย่างไร

Firebase service เปิดเผยรูปร่าง URL ที่รู้จักกันดีและคาดเดาได้ สแกนเนอร์ที่ไม่มี credential สามารถตรวจสอบแต่ละอันและสังเกตว่าการอ่านแบบ anonymous สำเร็จหรือไม่ check baas.firebase-rules ของ FixVibe ทำงานในสาม probe อิสระ — หนึ่งต่อ Firebase service:

• <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 หาก root อ่านได้แบบ anonymous response คือ tree ฐานข้อมูลทั้งหมดเป็น JSON การทดสอบที่อนุรักษ์นิยมกว่าจะ query .json?shallow=true ซึ่งคืนเฉพาะ key ระดับบนสุด — เป็น finding ทั้งสองทาง
• Cloud Storage สแกนเนอร์ query https://firebasestorage.googleapis.com/v0/b/[project-id].appspot.com/o หาก response list ชื่อไฟล์โดยไม่ต้อง authenticate, bucket นั้น anon-listable Storage ที่ list ได้คือ finding แม้ว่าการดาวน์โหลดไฟล์แต่ละอันจะถูกปฏิเสธ — ผู้โจมตี enumerate bucket เพื่อหาชื่อไฟล์ที่คาดเดาได้

footgun ของ test mode มีหน้าตาอย่างไร

เอกสาร quickstart ของ Firebase รวมหนึ่งใน rule block ที่ถูก copy มากที่สุดบนอินเทอร์เน็ต:

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

Firebase เคยเพิ่มการหมดอายุอัตโนมัติ 30 วันบน rule เหล่านี้ สิ่งนั้นเปลี่ยนไป: วันนี้ rule คงอยู่ตลอดไปเว้นแต่ developer จะแทนที่มัน เครื่องมือ AI Coding — ที่ฝึกบนเอกสารหลายปีที่รวม test-mode block — มักปล่อยมันออกมาแบบ verbatim และบอก developer ว่า "นี่คือ rule ความปลอดภัยของคุณ" มันไม่ใช่

อีกหลายรูปแบบที่ปรากฏใน production แต่ permissive เท่ากัน:

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

• รูปแบบ timestamp ในอนาคต: rule ที่อนุญาตทุกอย่างจนถึงวันที่ในอนาคตอันไกล ไม่หมดอายุอย่างมีประสิทธิภาพ (ดู block ที่ highlight ด้านบน)
• allow read: if true; allow write: if request.auth != null; — อ่านสาธารณะ, ผู้ใช้ที่ผ่านการ authenticate คนใดก็เขียนได้
• allow read, write: if request.auth != null; — ผู้ใช้ที่เข้าสู่ระบบคนใดสามารถอ่านหรือเขียน document ใดก็ได้ รวมถึงข้อมูลของผู้ใช้อื่น

จะทำอย่างไรเมื่อสแกนเนอร์พบ rule ที่เปิดอยู่

Firebase rule ที่เปิดอยู่คือเหตุฉุกเฉิน runtime การแก้ไขมีรูปร่างเดียวกันใน service ทั้งสาม: จำกัดทุก rule ไปยัง request.auth.uid เทียบกับ field เจ้าของที่ชัดเจน แต่ละ service มี rule syntax ของตัวเอง:

Firestore

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; } path-segment binding {userId} กลายเป็น document เดียวที่ผู้ใช้สามารถสัมผัสได้

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] และให้ path บังคับความเป็นเจ้าของ

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

Deploy rule ผ่าน Firebase CLI: firebase deploy --only firestore:rules, firebase deploy --only database, firebase deploy --only storage ยืนยันว่า rule ใหม่อยู่ใน production โดยการรัน FixVibe scan ใหม่ — finding baas.firebase-rules ควรหายไป

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

เปรียบเทียบกับเครื่องมือในตัวของ Firebase อย่างไร

Firebase Console แสดง rule ปัจจุบันแต่ไม่ audit เทียบกับพฤติกรรม runtime Firebase Rules simulator ให้คุณทดสอบ logic ของ rule เทียบกับ request สังเคราะห์ — มีประโยชน์แต่ local เครื่องมือทั้งสองไม่บอกคุณว่า rule production ของคุณคืนอะไรจริง ๆ ให้กับผู้โจมตี anonymous บนอินเทอร์เน็ตสาธารณะ สแกนเนอร์ภายนอกอย่าง FixVibe (หรือ Burp Suite พร้อมการตั้งค่าด้วยมือ) เป็นสิ่งเดียวที่ตรวจสอบจากมุมที่ผู้โจมตีจะทำ App Check ของ Google เองบรรเทาการละเมิดแต่ไม่ใช่การทดแทน rule ที่จำกัดอย่างถูกต้อง

คำถามที่พบบ่อย

ขั้นตอนถัดไป

รัน FixVibe scan ฟรีกับ URL production ของคุณ — check baas.firebase-rules มาในทุกแพ็กเกจและแจ้ง rule ที่เปิดอยู่ใน Firestore, Realtime Database และ Cloud Storage สำหรับคำอธิบายเชิงลึกเกี่ยวกับ pattern allow read, write: if true โดยเฉพาะ โปรดดู Firebase allow read, write: if true อธิบาย สำหรับมุมมองภาพรวมข้าม Supabase, Firebase, Clerk และ Auth0 อ่าน BaaS misconfiguration scanner