// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true อธิบาย: มันทำอะไรและจะแก้ไขอย่างไร

Q: ความแตกต่างระหว่าง if true และ if request.auth != null คืออะไร?

if true อนุญาตการเข้าถึงแบบ anonymous — ใครก็ได้บนอินเทอร์เน็ต if request.auth != null ต้องการผู้ใช้ที่เข้าสู่ระบบใด ๆ ซึ่งดีกว่าแต่ยังคงผิด: ผู้ใช้แอปคุณคนใดก็สามารถอ่านข้อมูลของผู้ใช้ทุกคนอื่นได้ rule สำหรับ production ต้องจำกัดไปยังผู้ใช้หรือ org ที่เจาะจงผ่าน request.auth.uid == resource.data.owner_uid หรือคล้ายกัน

Q: Firebase หมดอายุ rule if true โดยอัตโนมัติหรือไม่?

โปรเจกต์เก่า (ก่อน 2023) มี timer 30 วันที่แปลง rule if true เป็น if false โปรเจกต์ปัจจุบันไม่มี — rule คงอยู่อย่างไม่จำกัดจนกว่าจะถูกแทนที่ด้วยตนเอง หากคุณสร้างโปรเจกต์ก่อน 2023 และ rule ของคุณดูดี ตรวจสอบสองครั้ง: timer อาจเปลี่ยนมันเป็น if false ไปแล้ว ซึ่งบล็อกแอปของคุณเอง

Q: ถ้าแอปของฉันอ่านสาธารณะจริง ๆ (blog, product catalog) ?

ในกรณีนั้นเขียน allow read: if true; allow write: if false; ที่ชัดเจนเฉพาะ collection สาธารณะ — ไม่ใช่ทุก collection ในฐานข้อมูล ใช้ match clause แยกต่อ collection และไม่ใช้ '{'document=**'}' wildcard แบบ recursive บน rule ที่เขียนได้

<code>allow read, write: if true;</code> เป็นการตั้งค่าผิด Firebase ที่พบบ่อยที่สุดเพียงอย่างเดียวใน production มันคือค่าเริ่มต้น test-mode ที่ Firebase Console แนะนำเมื่อคุณสร้างฐานข้อมูลใหม่, rule ที่เครื่องมือ AI Coding สร้างซ้ำจากเอกสาร และ rule ที่เปิดฐานข้อมูล Firestore ทั้งหมดของคุณให้กับใครก็ตามบนอินเทอร์เน็ต บทความนี้อธิบาย syntax อย่างแม่นยำ, แสดงสิ่งที่ผู้โจมตีเห็นเมื่อ rule นี้ live และให้สี่ตัวแทนที่เข้มงวดขึ้นเรื่อย ๆ ที่เหมาะกับกรณีใช้งานต่างกัน

Syntax บรรทัดต่อบรรทัด

เอกสาร rule Firestore test-mode ที่สมบูรณ์มีหกบรรทัด:

firebase

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

ถอดรหัส:

rules_version = '2'; เลือก rules engine v2 (ปัจจุบัน) rule v1 ที่เก่ากว่าเลิกใช้แล้ว
service cloud.firestore จำกัด block ไปยัง Firestore Realtime Database ใช้ syntax JSON-based ต่างกัน; Cloud Storage ใช้ service firebase.storage
match /databases/{database}/documents จับฐานข้อมูล (default) พิเศษ (โปรเจกต์ส่วนใหญ่มีแค่หนึ่ง)
match /{document=**} เป็น wildcard แบบ recursive ** จับ path ใด ๆ ที่มีความลึกเท่าใดก็ได้ รวมกับ {document} มันจับทุก document ในทุก collection — match clause เดียวที่ควบคุมฐานข้อมูลทั้งหมด
allow read, write: if true; คือเนื้อหา rule ทั้ง read และ write ได้รับอนุญาต; เงื่อนไข if true ก็เป็นจริงเสมอ read ครอบคลุมการดำเนินการ get และ list; write ครอบคลุม create, update และ delete

ผลสุทธิ: client ใดก็ตามที่มี Firebase project ID และ SDK ที่ถูกต้องสามารถอ่านหรือเขียน document ใดในcollection ใดได้ ไม่ต้องการ authentication ไม่บังคับ rate limit

ทำไม Firebase ส่งสิ่งนี้เป็นค่าเริ่มต้น

Firebase ต้องการให้คุณ code ใน 30 วินาทีแรกหลังจากสร้างโปรเจกต์ ทางเลือก — ทำให้คุณเขียน rule ที่ถูกต้องก่อนการอ่านหรือเขียนใด ๆ จะทำงาน — จะบล็อกการ onboard ดังนั้น Console เสนอสองตัวเลือกเมื่อคุณสร้างฐานข้อมูล: Production mode (ปฏิเสธทุกอย่าง คุณเขียน rule) หรือ Test mode (อนุญาตทุกอย่างเป็นเวลา 30 วัน) developer ส่วนใหญ่คลิก test mode แล้วลืมกลับมาตรวจสอบ โปรเจกต์เก่ามี timer 30 วัน; โปรเจกต์ปัจจุบันมี rule if true ที่ไม่จำกัดเวลาโดยไม่มีการหมดอายุอัตโนมัติ

ปัญหาเชิงโครงสร้าง: เครื่องมือ AI Coding ฝึกบนเอกสาร, tutorial และคำตอบ Stack Overflow ที่แสดง rule test-mode เมื่อคุณถาม Cursor หรือ Claude Code ว่า "ฉันจะตั้งค่า Firebase อย่างไร" คำตอบมักรวม block allow read, write: if true ที่แน่นอนราวกับว่าเป็น rule production AI ไม่รู้ — และไม่ถูกกระตุ้นให้รู้ — ว่า rule นี้ไม่ปลอดภัยสำหรับ production

สิ่งที่ผู้โจมตีเห็น

เป็นรูปธรรม ผู้โจมตีที่รู้ Firebase project ID ของคุณ (ดึงได้จาก bundle ของแอปที่ deploy แล้วใน 30 วินาที) และรันสิ่งต่อไปนี้สามารถ list ทุก document ในทุก collection:

request curl ที่ไม่ผ่านการ authenticate ครั้งเดียวเพียงพอที่จะ enumerate ทุก collection ดู block ที่ highlight ด้านล่าง

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

response คือรายการ collection ระดับบนสุดทั้งหมด สำหรับแต่ละ collection request ที่สองคืน document ไม่มี rate limit บน path นี้เพราะ rule if true ยอมรับ traffic anonymous เราเห็นฐานข้อมูล Firebase ที่มี document นับล้านถูก enumerate ในเวลาไม่ถึงหนึ่งชั่วโมง

บน write path: POST เดียวกับ {fields} สร้าง document ใหม่ ผู้โจมตีสามารถทำให้ collection ของคุณเต็มไปด้วยขยะ, ทำลายหน้าที่ผู้ใช้เห็นที่อ่านจาก Firestore หรือใช้ฐานข้อมูลของคุณเป็น message broker ฟรี — bill การใช้งานของคุณพุ่งสูง คุณตรวจสอบ bill อธิบายปัญหา

สี่ตัวแทนที่ปลอดภัยสำหรับ production

เลือกตัวแทนที่ที่ตรงกับ data model ของแอปคุณ ทั้งสี่สมมติว่าคุณมี user authentication (Firebase Auth หรือ provider ใดก็ตามที่ออก Firebase ID token):

ตัวเลือกที่ 1: document ที่ผู้ใช้เป็นเจ้าของ

pattern SaaS ที่พบบ่อยที่สุด document อยู่ใต้ /users/{userId}/... และเฉพาะเจ้าของเท่านั้นที่สัมผัสได้ match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

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

ตัวเลือกที่ 2: field เจ้าของในทุก document

เมื่อ document อยู่ใน collection แบนราบ (ไม่ได้ซ้อนใต้ user ID) เก็บ field owner_uid และตรวจสอบ match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

ตัวเลือกที่ 3: การแยก org แบบ multi-tenant

สำหรับ B2B SaaS ที่มีข้อมูลจำกัดตาม org เก็บ field org_id ในทุก document และตรวจสอบเทียบกับ custom claim ของผู้ใช้ allow read, write: if request.auth.token.org_id == resource.data.org_id; ต้องตั้ง custom claim ตอนสมัครสมาชิกผ่าน Firebase Admin SDK

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

ตัวเลือกที่ 4: เนื้อหาสาธารณะอ่านอย่างเดียว

สำหรับเนื้อหาการตลาด, public profile, product catalog — อะไรก็ตามที่เป็นการอ่านสาธารณะจริง ๆ แต่เขียนได้เฉพาะ admin match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; } custom claim admin ตั้งเฉพาะบัญชี admin เท่านั้น

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Query audit ด่วน

ก่อนแก้ไข ตรวจสอบว่า if true live จริงหรือไม่ เปิด Firebase Console → Firestore → Rules และค้นหา if true ถ้าคุณพบที่ไหนนอกความคิดเห็น คุณมี finding rule ที่เปิดอยู่ Rules simulator ใน UI เดียวกันให้คุณ replay request ของผู้โจมตีในเครื่อง — วาง GET /users/somebody แบบ anonymous และยืนยันว่า simulator คืน Allowed

การยืนยันภายนอก: รัน FixVibe scan กับ URL production ของคุณ check baas.firebase-rules ตรวจสอบ rule ของ Firestore, Realtime Database และ Storage และรายงาน finding เดียวกับที่ผู้โจมตีจะค้นพบ — แยกจากสิ่งที่ Firebase Console แสดง

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

ความแตกต่างระหว่าง <code>if true</code> และ <code>if request.auth != null</code> คืออะไร?

if true อนุญาตการเข้าถึงแบบ anonymous — ใครก็ได้บนอินเทอร์เน็ต if request.auth != null ต้องการผู้ใช้ที่เข้าสู่ระบบใด ๆ ซึ่งดีกว่าแต่ยังคงผิด: ผู้ใช้แอปคุณคนใดก็สามารถอ่านข้อมูลของผู้ใช้ทุกคนอื่นได้ rule สำหรับ production ต้องจำกัดไปยังผู้ใช้หรือ org ที่เจาะจงผ่าน request.auth.uid == resource.data.owner_uid หรือคล้ายกัน

Firebase หมดอายุ rule <code>if true</code> โดยอัตโนมัติหรือไม่?

โปรเจกต์เก่า (ก่อน 2023) มี timer 30 วันที่แปลง rule if true เป็น if false โปรเจกต์ปัจจุบันไม่มี — rule คงอยู่อย่างไม่จำกัดจนกว่าจะถูกแทนที่ด้วยตนเอง หากคุณสร้างโปรเจกต์ก่อน 2023 และ rule ของคุณดูดี ตรวจสอบสองครั้ง: timer อาจเปลี่ยนมันเป็น if false ไปแล้ว ซึ่งบล็อกแอปของคุณเอง

ฉันสามารถใช้การตรวจสอบ timestamp ในอนาคตเป็น safety net หรือไม่?

ไม่ — เงื่อนไข timestamp ไม่ใช่การควบคุมความปลอดภัย มันหมดอายุ rule ที่เปิดอยู่ในวันที่ในอนาคต ซึ่งหมายความว่าจนถึงวันที่นั้นผู้โจมตีมีสิทธิ์เข้าถึงเต็มที่ และคุณจะลืมวันที่ แทนที่ if true ด้วย rule ที่จำกัด auth ไม่ใช่ rule ที่จำกัดเวลา

ถ้าแอปของฉันอ่านสาธารณะจริง ๆ (blog, product catalog) ?

ในกรณีนั้นเขียน allow read: if true; allow write: if false; ที่ชัดเจนเฉพาะ collection สาธารณะ — ไม่ใช่ทุก collection ในฐานข้อมูล ใช้ match clause แยกต่อ collection และไม่ใช้ {document=**} wildcard แบบ recursive บน rule ที่เขียนได้

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

รัน FixVibe scan กับ URL production ของคุณ — check baas.firebase-rules ยืนยันว่า if true สามารถ exploit ได้จากอินเทอร์เน็ตสาธารณะหรือไม่ สำหรับกลไกสแกนเนอร์และการตรวจจับคู่ขนานสำหรับ Realtime Database และ Storage โปรดดู Firebase rules scanner สำหรับ class การตั้งค่าผิดที่เทียบเท่าบน Supabase อ่าน Supabase RLS scanner